Methods and systems for analyzing entity performance

ABSTRACT

Systems and methods are provided for analyzing entity performance. In one implementation, a method is provided that includes recognizing an identifier associated with an entity and accessing a data structure comprising information associated with a plurality of interactions. The method also comprises identifying one or more interactions of the plurality of interactions based on the recognized identifier. The method further comprises processing the information of the identified interactions to analyze a performance of the entity and providing the processed information to display the performance of the entity on a user interface.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent ApplicationNo. 61/916,795, U.S. Provisional Patent Application No. 61/916,796, andU.S. Provisional Patent Application No. 61/916,797, each of which werefiled on Dec. 16, 2013, and the disclosures of which are expresslyincorporated herein by reference in their entirety.

BACKGROUND

The amount of information being processed and stored is rapidlyincreasing as technology advances present an ever-increasing ability togenerate and store data. This data is commonly stored in computer-basedsystems in structured data stores. For example, one common type of datastore is a so-called “flat” file such as a spreadsheet, plain-textdocument, or XML document. Another common type of data store is arelational database comprising one or more tables. Other examples ofdata stores that comprise structured data include, without limitation,files systems, object collections, record collections, arrays,hierarchical trees, linked lists, stacks, and combinations thereof.

Numerous organizations, including industry, retail, and governmententities, recognize that important information and decisions can bedrawn if massive data sets can be analyzed to identify patterns ofbehavior. Collecting and classifying large sets of data in anappropriate manner allows these entities to more quickly and efficientlyidentify these patterns, thereby allowing them to make more informeddecisions.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will now be made to the accompanying drawings which illustrateexemplary embodiments of the present disclosure and in which:

FIG. 1 illustrates, in block diagram form, an exemplary data fusionsystem for providing interactive data analysis, consistent withembodiments of the present disclosure.

FIG. 2 is a block diagram of an exemplary system for analyzingperformance of an entity, consistent with embodiments of the presentdisclosure.

FIG. 3 is a block diagram of an exemplary computer system, consistentwith embodiments of the present disclosure.

FIG. 4 is a block diagram of an exemplary data structure accessed in theprocess of analyzing entity performance, consistent with the embodimentsof the present disclosure.

FIG. 5 is a block diagram of an exemplary scenario depicting a systemfor analyzing entity performance, consistent with the embodiments of thepresent disclosure.

FIG. 6 is a flowchart representing an exemplary process for analyzingentity performance, consistent with the embodiments of the presentdisclosure.

FIG. 7 is a screenshot of an exemplary user interface representing anentity performance, consistent with embodiments of the presentdisclosure.

FIG. 8 is a screenshot of an exemplary user interface representing anentity performance, consistent with embodiments of the presentdisclosure.

FIG. 9 is a screenshot of an exemplary user interface representing anentity performance, consistent with embodiments of the presentdisclosure.

FIG. 10A is a flowchart representing an exemplary process for analyzingentity performance, consistent with the embodiments of the presentdisclosure.

FIG. 10B is a screenshot of an exemplary user interface representing anentity performance, consistent with embodiments of the presentdisclosure.

FIG. 11 is a flowchart representing an exemplary process for comparingentity performance, consistent with the embodiments of the presentdisclosure.

FIG. 12 is a screenshot of an exemplary user interface representing acomparison of entity performance, consistent with embodiments of thepresent disclosure

FIG. 13 is a flowchart representing an exemplary process for estimatinga consuming entity's location, consistent with the embodiments of thepresent disclosure.

FIG. 14 is a flowchart representing an exemplary process for estimatinga provisioning entity's location, consistent with the embodiments of thepresent disclosure.

FIG. 15 is a flowchart representing an exemplary process for estimatinga provisioning entity's location, consistent with the embodiments of thepresent disclosure.

FIGS. 16A, 16B, and 16C are block diagrams representing a method ofcomputing travel times between two provisioning entities, consistentwith the embodiments of the present disclosure.

FIGS. 17-26 are screenshots of exemplary user interfaces, consistentwith the embodiments of the present disclosure.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

This application expressly incorporates herein by reference the entiretyof U.S. Non-Provisional patent application Ser. No. 14/045,720, titled“Systems and Methods for Analyzing Performance of an Entity”, filed onOct. 3, 2013.

Reference will now be made in detail to the embodiments, the examples ofwhich are illustrated in the accompanying drawings. Whenever possible,the same reference numbers will be used throughout the drawings to referto the same or like parts. The terms interactions and transactions areintended to covey the same meaning and can be used interchangeablythroughout this disclosure.

FIG. 1 illustrates, in block diagram form, an exemplary data fusionsystem 100 for providing interactive data analysis, consistent withembodiments of the present disclosure. Among other things, data fusionsystem 100 facilitates transformation of one or more data sources, suchas data sources 130 (e.g., financial services systems 220, geographicdata systems 230, provisioning entity management systems 240 and/orconsuming entity data systems 250, as shown in FIG. 2) into an objectmodel 160 whose semantics are defined by an ontology 150. Thetransformation can be performed for a variety of reasons. For example, adatabase administrator can import data from data sources 130 into adatabase 170 for persistently storing object model 160. As anotherexample, a data presentation component (not depicted) can transforminput data from data sources 130 “on the fly” into object model 160. Theobject model 160 can then be utilized, in conjunction with ontology 150,for analysis through graphs and/or other data visualization techniques.

Data fusion system 100 comprises a definition component 110 and atranslation component 120, both implemented by one or more processors ofone or more computing devices or systems executing hardware and/orsoftware-based logic for providing various functionality and features ofthe present disclosure, as described herein. As will be appreciated fromthe present disclosure, data fusion system 100 can comprise fewer oradditional components that provide the various functionalities andfeatures described herein. Moreover, the number and arrangement of thecomponents of data fusion system 100 responsible for providing thevarious functionalities and features described herein can further varyfrom embodiment to embodiment.

Definition component 110 generates and/or modifies ontology 150 and aschema map 140. Exemplary embodiments for defining an ontology (such asontology 150) are described in U.S. Pat. No. 7,962,495 (the '495patent), issued on Jun. 14, 2011, the entire contents of which areexpressly incorporated herein by reference for all purposes. Consistentwith certain embodiments disclosed in the '495 patent, a dynamicontology may be used to create a database. To create a databaseontology, one or more object types may be defined, where each objecttype includes one or more properties. The attributes of object types orproperty types of the ontology can be edited or modified at any time.And, for each property type, at least one parser definition may becreated. The attributes of a parser definition can be edited or modifiedat any time.

In some embodiments, each property type is declared to be representativeof one or more object types. A property type is representative of anobject type when the property type is intuitively associated with theobject type. Alternatively, each property type has one or morecomponents and a base type. In some embodiments, a property type cancomprise a string, a date, a number, or a composite type consisting oftwo or more string, date, or number elements. Thus, property types areextensible and can represent complex data structures. Further, a parserdefinition can reference a component of a complex property type as aunit or token.

An example of a property having multiple components is an Addressproperty having a City component and a State component. An example ofraw input data is “Los Angeles, Calif.” An example parser definitionspecifies an association of imported input data to object propertycomponents as follows: {CITY}, {STATE}→Address:State, Address:City. Insome embodiments, the association {CITY}, {STATE} is defined in a parserdefinition using regular expression symbology. The association {CITY},{STATE} indicates that a city string followed by a state string, andseparated by a comma, comprises valid input data for a property of typeAddress. In contrast, input data of “Los Angeles Calif.” would not bevalid for the specified parser definition, but a user could create asecond parser definition that does match input data of “Los AngelesCalif.” The definition Address:City, Address:State specifies thatmatching input data values map to components named “City” and “State” ofthe Address property. As a result, parsing the input data using theparser definition results in assigning the value “Los Angeles” to theAddress:City component of the Address property, and the value “CA” tothe Address:State component of the Address property.

According to some embodiments, schema map 140 can define how variouselements of schemas 135 for data sources 130 map to various elements ofontology 150. Definition component 110 receives, calculates, extracts,or otherwise identifies schemas 135 for data sources 130. Schemas 135define the structure of data sources 130; for example, the names andother characteristics of tables, files, columns, fields, properties, andso forth. Definition component 110 furthermore optionally identifiessample data 136 from data sources 130. Definition component 110 canfurther identify object type, relationship, and property definitionsfrom ontology 150, if any already exist. Definition component 110 canfurther identify pre-existing mappings from schema map 140, if suchmappings exist.

Based on the identified information, definition component 110 cangenerate a graphical user interface 115. Graphical user interface 115can be presented to users of a computing device via any suitable outputmechanism (e.g., a display screen, an image projection, etc.), and canfurther accept input from users of the computing device via any suitableinput mechanism (e.g., a keyboard, a mouse, a touch screen interface,etc.). Graphical user interface 115 features a visual workspace thatvisually depicts representations of the elements of ontology 150 forwhich mappings are defined in schema map 140.

In some embodiments, transformation component 120 can be invoked afterschema map 140 and ontology 150 have been defined or redefined.Transformation component 120 identifies schema map 140 and ontology 150.Transformation component 120 further reads data sources 130 andidentifies schemas 135 for data sources 130. For each element ofontology 150 described in schema map 140, transformation component 120iterates through some or all of the data items of data sources 130,generating elements of object model 160 in the manner specified byschema map 140. In some embodiments, transformation component 120 canstore a representation of each generated element of object model 160 ina database 170. In some embodiments, transformation component 120 isfurther configured to synchronize changes in object model 160 back todata sources 130.

Data sources 130 can be one or more sources of data, including, withoutlimitation, spreadsheet files, databases, email folders, documentcollections, media collections, contact directories, and so forth. Datasources 130 can include data structures stored persistently innon-volatile memory. Data sources 130 can also or alternatively includetemporary data structures generated from underlying data sources viadata extraction components, such as a result set returned from adatabase server executing an database query.

Schema map 140, ontology 150, and schemas 135 can be stored in anysuitable structures, such as XML files, database tables, and so forth.In some embodiments, ontology 150 is maintained persistently. Schema map140 can or cannot be maintained persistently, depending on whether thetransformation process is perpetual or a one-time event. Schemas 135need not be maintained in persistent memory, but can be cached foroptimization.

Object model 160 comprises collections of elements such as typedobjects, properties, and relationships. The collections can bestructured in any suitable manner. In some embodiments, a database 170stores the elements of object model 160, or representations thereof.Alternatively, the elements of object model 160 are stored withindatabase 170 in a different underlying format, such as in a series ofobject, property, and relationship tables in a relational database.

According to some embodiments, the functionalities, techniques, andcomponents described herein are implemented by one or morespecial-purpose computing devices. The special-purpose computing devicescan be hard-wired to perform the techniques, or can include digitalelectronic devices such as one or more application-specific integratedcircuits (ASICs) or field programmable gate arrays (FPGAs) that arepersistently programmed to perform the techniques, or can include one ormore general purpose hardware processors programmed to perform thetechniques pursuant to program instructions in firmware, memory, otherstorage, or a combination. Such special-purpose computing devices canalso combine custom hard-wired logic, ASICs, or FPGAs with customprogramming to accomplish the techniques. The special-purpose computingdevices can be desktop computer systems, portable computer systems,handheld devices, networking devices, or any other device thatincorporates hard-wired and/or program logic to implement thetechniques.

Throughout this disclosure, reference will be made to an entity such as,for example, a provisioning entity and a consuming entity. It will beunderstood that a provisioning entity can include, for example, amerchant, a retail provisioning entity or the like, and a consumingentity can include, for example, a consumer user buying products orservices from a provisioning entity. It will be understood that aconsuming entity can represent either individual persons or canrepresent a group of persons (e.g., a group of persons living under oneroof as part of a family). In some embodiments, a consuming entity canbe a credit card number of an individual or a credit card number for anentire family sharing one credit card. It will also be understood that aprovisioning entity can represent either the entity itself or individualpersons involved with the entity.

In embodiments described herein, data fusion system 100 can provide aprovisioning entity, such as a retail provisioning entity, to analyzeinformation to identify behaviors to allow that provisioning entity tomake more informed decisions. Such information can allow retailentities, such as a retail provisioning entity, to determine where toplace their retail locations. Provisioning entities having more than onelocation (e.g., a merchant with a chain store or a franchise model)typically evaluate the performance of their locations and may adjusttheir business models or work flows when the locations under-perform.Typically, provisioning entities evaluate the performance of theirlocations based on period-to-period metrics. For example, a provisioningentity can evaluate a location's performance by comparing the currentmonth's sales to the previous month's sales. In addition, provisioningentitles can evaluate each of its locations' performance usingcomparative analysis. For example, a provisioning entity might comparethe sales at an area location with the sales at a second location. Asprovisioning entities generally measure the performance of its locationsbased on their own interaction data (e.g., the entity's sales acrosssome or all of its locations), current methods of measuring performancedo not consider sales made by competitors or demographic features of theareas of the provisioning entity's locations.

Since current performance evaluation methods do not consider the salesof competitors or the demographic features of the region of theprovisioning entity location, measured performance may not represent thetrue performance of a provisioning entity. For instance, although aprovisioning entity location in a low consumer spend capacity area mighthave less sales than a provisioning entity location in a high consumerspend capacity area, it may be performing better than what could beexpected for that area in light of, for example, the low number ofconsumers residing in the area or the low income of the area. Aperformance of a provisioning entity at an area location can beadversely impacted by the close proximity of a second location of theprovisioning entity, but the provisioning entity at the area locationcan be performing better than expected given the competition from theprovisioning entity's second location. Conversely, while a provisioningentity location in a dense, high-income area might have the highestsales of all provisioning entity locations, it can still beunder-performing because, for instance, consumer spend capacity is highand the provisioning entity location could generate more sales.

Consistent with embodiments of the present disclosure, the performanceof provisioning entities can be analyzed based on how the provisioningentity is expected to perform given the location of the provisioningentity. For a given provisioning entity location, the disclosedembodiments may be implemented to consider, for example, consumerdemographic features of the provisioning entity location's area and theproximity of competitors to the provisioning entity location (includingthe proximity of the provisioning entity's other close-by locations). Insome embodiments, the provisioning entity can be a merchant. Forpurposes of illustration, exemplary embodiments for analyzing entityperformance are described herein with reference to “merchants.” Theexemplary embodiments and techniques described herein, however, may beapplied to other types of entities (e.g., service providers,governmental agencies, etc.) within the spirit and scope of thisdisclosure.

FIG. 2 is a block diagram of an exemplary system 200 for performing oneor more operations for analyzing performance of a provisioning entityand/or a consuming entity, consistent with disclosed embodiments. Insome embodiments, the provisioning entity is a merchant and system 200can include provisioning entity analysis system 210, one or morefinancial services systems 220, one or more geographic data systems 230,one or more provisioning entity management systems 240, and one or moreconsuming entity data systems 250. The components and arrangement of thecomponents included in system 200 can vary depending on the embodiment.For example, the functionality described below with respect to financialservices systems 220 can be embodied in consuming entity data systems250, or vice-versa. Thus, system 200 can include fewer or additionalcomponents that perform or assist in the performance of one or moreprocesses to analyze provisioning entity's, consistent with thedisclosed embodiments.

One or more components of system 200 can be computing systems configuredto analyze provisioning entity performance. As further described herein,components of system 200 can include one or more computing devices(e.g., computer(s), server(s), etc.), memory storing data and/orsoftware instructions (e.g., database(s), memory devices, etc.), andother known computing components. In some embodiments, the one or morecomputing devices are configured to execute software or a set ofprogrammable instructions stored on one or more memory devices toperform one or more operations, consistent with the disclosedembodiments. Components of system 200 can be configured to communicatewith one or more other components of system 200, including provisioningentity analysis system 210, one or more financial services systems 220,one or more geographic data systems 230, one or more provisioning entitymanagement systems 240, and one or more consumer data systems 250. Incertain aspects, users can operate one or more components of system 200.The one or more users can be employees of, or associated with, theentity corresponding to the respective component(s) (e.g., someoneauthorized to use the underlying computing systems or otherwise act onbehalf of the entity).

Provisioning entity analysis system 210 can be a computing systemconfigured to analyze provisioning entity performance. For example,provisioning entity analysis system 210 can be a computer systemconfigured to execute software or a set of programmable instructionsthat collect or receive financial interaction data, consumer data, andprovisioning entity data and process it to determine the actualtransaction amount of each transaction associated with the provisioningentity. Provisioning entity analysis system 210 can be configured, insome embodiments, to utilize, include, or be a data fusion system 100(see, e.g., FIG. 1) to transform data from various data sources (suchas, financial services systems 220, geographic data systems 230,provisioning entity management systems 240, and consuming entity datasystems 250) for processing. In some embodiments, provisioning entityanalysis system 210 can be implemented using a computer system 300, asshown in FIG. 3 and described below.

Provisioning entity analysis system 210 can include one or morecomputing devices (e.g., server(s)), memory storing data and/or softwareinstructions (e.g., database(s), memory devices, etc.) and other knowncomputing components. According to some embodiments, provisioning entityanalysis system 210 can include one or more networked computers thatexecute processing in parallel or use a distributed computingarchitecture. Provisioning entity analysis system 210 can be configuredto communicate with one or more components of system 200, and it can beconfigured to provide analysis of provisioning entities via aninterface(s) accessible by users over a network (e.g., the Internet).For example, provisioning entity analysis system 210 can include a webserver that hosts a web page accessible through network 260 byprovisioning entity management systems 240. In some embodiments,provisioning entity analysis system 210 can include an applicationserver configured to provide data to one or more client applicationsexecuting on computing systems connected to provisioning entity analysissystem 210 via network 260.

In some embodiments, provisioning entity analysis system 210 can beconfigured to determine the actual sales for a provisioning entity orspecific provisioning entity location by processing and analyzing datacollected from one or more components of system 200. For example,provisioning entity analysis system 210 can determine that the Big BoxMerchant store located at 123 Main St, in Burbank, Calif. is actuallygenerating $60,000 of sales per month. Provisioning entity analysissystem 210 can provide an analysis of a provisioning entity orprovisioning entity location's performance based on a target for salesand the actual sales for the provisioning entity or provisioning entitylocation. For example, for the Big Box Merchant store located at 123Main St., Burbank, Calif., the provisioning entity analysis system 210can provide an analysis that the store is performing above expectations.Exemplary processes that can be used by provisioning entity analysissystem 210 are described below with respect to FIGS. 6, 10A, 11, 13, 14,and 15.

Provisioning entity analysis system 210 can, in some embodiments,generate a user interface communicating data related to one or moreprovisioning entities or provisioning entity locations. For example, insome embodiments, provisioning entity analysis system 210 includes a webserver that generates HTML code, or scripts capable of generating HTMLcode, that can be displayed in a web browser executing on computingdevice. Provisioning entity analysis system 210 can also execute anapplication server that provides user interface objects to a clientapplication executing on a computing device, or it can provide data thatis capable of being displayed in a user interface in a clientapplication executing on a computing device. In some embodiments,provisioning entity analysis system 210 can generate user interfacesthat can be displayed within another user interface. For example,provisioning entity analysis system 210 can generate a user interfacefor display within a parent user interface that is part of a wordprocessing application, a presentation development application, a webbrowser, or an illustration application, among others. In someembodiments, generating a user interface can include generating the codethat when executed displays information (e.g., HTML) on the userinterface. Alternatively, generating interface can include providingcommands and/or data to a set of instructions that when executed rendera user interface capable of being shown on a display connected to acomputing device. In some embodiments, the user interface can include amap, indications of the provisioning entity locations on a map, andindications of the sales or interactions associated with theprovisioning entity locations. Examples of some (although not all) userinterfaces that can be generated by provisioning entity analysis system210 are described below with respect to FIGS. 7-9, 10B and 12.

Referring again to FIG. 2, financial services system 220 can be acomputing system associated with a financial service provider, such as abank, credit card issuer, credit bureau, credit agency, or other entitythat generates, provides, manages, and/or maintains financial serviceaccounts for one or more users. Financial services system 220 cangenerate, maintain, store, provide, and/or process financial dataassociated with one or more financial service accounts. Financial datacan include, for example, financial service account data, such asfinancial service account identification data, account balance,available credit, existing fees, reward points, user profileinformation, and financial service account interaction data, such asinteraction dates, interaction amounts, interaction types, and locationof interaction. In some embodiments, each interaction of financial datacan include several categories of information associated with theinteraction. For example, each interaction can include categories suchas number category; consuming entity identification category; consumingentity location category; provisioning entity identification category;provisioning entity location category; type of provisioning entitycategory; interaction amount category; and time of interaction category,as described in FIG. 4. It will be appreciated that financial data cancomprise either additional or fewer categories than the exemplarycategories listed above. Financial services system 220 can includeinfrastructure and components that are configured to generate and/orprovide financial service accounts such as credit card accounts,checking accounts, savings account, debit card accounts, loyalty orreward programs, lines of credit, and the like.

Geographic data systems 230 can include one or more computing devicesconfigured to provide geographic data to other computing systems insystem 200 such as provisioning entity analysis system 210. For example,geographic data systems 230 can provide geodetic coordinates whenprovided with a street address of vice-versa. In some embodiments,geographic data systems 230 exposes an application programming interface(API) including one or more methods or functions that can be calledremotely over a network, such as network 260. According to someembodiments, geographic data systems 230 can provide informationconcerning routes between two geographic points. For example,provisioning entity analysis system 210 can provide two addresses andgeographic data systems 230 can provide, in response, the aerialdistance between the two addresses, the distance between the twoaddresses using roads, and/or a suggested route between the twoaddresses and the route's distance.

According to some embodiments, geographic data systems 230 can alsoprovide map data to provisioning entity analysis system 210 and/or othercomponents of system 200. The map data can include, for example,satellite or overhead images of a geographic region or a graphicrepresenting a geographic region. The map data can also include pointsof interest, such as landmarks, malls, shopping centers, schools, orpopular restaurants or retailers, for example.

Provisioning entity management systems 240 can be one or more computingdevices configured to perform one or more operations consistent withdisclosed embodiments. For example, provisioning entity managementsystems 240 can be a desktop computer, a laptop, a server, a mobiledevice (e.g., tablet, smart phone, etc.), or any other type of computingdevice configured to request provisioning entity analysis fromprovisioning entity analysis system 210. According to some embodiments,provisioning entity management systems 240 can comprise anetwork-enabled computing device operably connected to one or more otherpresentation devices, which can themselves constitute a computingsystem. For example, provisioning entity management systems 240 can beconnected to a mobile device, telephone, laptop, tablet, or othercomputing device.

Provisioning entity management systems 240 can include one or moreprocessors configured to execute software instructions stored in memory.Provisioning entity management systems 240 can include software or a setof programmable instructions that when executed by a processor performsknown Internet-related communication and content presentation processes.For example, provisioning entity management systems 240 can executesoftware or a set of instructions that generates and displays interfacesand/or content on a presentation device included in, or connected to,provisioning entity management systems 240. In some embodiments,provisioning entity management systems 240 can be a mobile device thatexecutes mobile device applications and/or mobile device communicationsoftware that allows provisioning entity management systems 240 tocommunicate with components of system 200 over network 260. Thedisclosed embodiments are not limited to any particular configuration ofprovisioning entity management systems 240.

Provisioning entity management systems 240 can be one or more computingsystems associated with a provisioning entity that provides products(e.g., goods and/or services), such as a restaurant (e.g., OutbackSteakhouse®, Burger King®, etc.), retailer (e.g., Amazon.com®, Target®,etc.), grocery store, mall, shopping center, service provider (e.g.,utility company, insurance company, financial service provider,automobile repair services, movie theater, etc.), non-profitorganization (ACLU™, AARP®, etc.) or any other type of entity thatprovides goods, services, and/or information that consuming entities(i.e., end-users or other business entities) can purchase, consume, use,etc. For ease of discussion, the exemplary embodiments presented hereinrelate to purchase interactions involving goods from retail provisioningentity systems. Provisioning entity management systems 240, however, isnot limited to systems associated with retail provisioning entities thatconduct business in any particular industry or field.

Provisioning entity management systems 240 can be associated withcomputer systems installed and used at a brick and mortar provisioningentity locations where a consumer can physically visit and purchasegoods and services. Such locations can include computing devices thatperform financial service interactions with consumers (e.g., Point ofSale (POS) terminal(s), kiosks, etc.). Provisioning entity managementsystems 240 can also include back- and/or front-end computing componentsthat store data and execute software or a set of instructions to performoperations consistent with disclosed embodiments, such as computers thatare operated by employees of the provisioning entity (e.g., back officesystems, etc.). Provisioning entity management systems 240 can also beassociated with a provisioning entity that provides goods and/or servicevia known online or e-commerce types of solutions. For example, such aprovisioning entity can sell products via a website using known onlineor e-commerce systems and solutions to market, sell, and process onlineinteractions. Provisioning entity management systems 240 can include oneor more servers that are configured to execute stored software or a setof instructions to perform operations associated with a provisioningentity, including one or more processes associated with processingpurchase interactions, generating interaction data, generating productdata (e.g., SKU data) relating to purchase interactions, for example.

Consuming entity data systems 250 can include one or more computingdevices configured to provide demographic data regarding consumers. Forexample, consuming entity data systems 250 can provide informationregarding the name, address, gender, income level, age, email address,or other information about consumers. Consuming entity data systems 250can include public computing systems such as computing systemsaffiliated with the U.S. Bureau of the Census, the U.S. Bureau of LaborStatistics, or FedStats, or it can include private computing systemssuch as computing systems affiliated with financial institutions, creditbureaus, social media sites, marketing services, or some otherorganization that collects and provides demographic data.

Network 260 can be any type of network or combination of networksconfigured to provide electronic communications between components ofsystem 200. For example, network 260 can be any type of network(including infrastructure) that provides communications, exchangesinformation, and/or facilitates the exchange of information, such as theInternet, a Local Area Network, or other suitable connection(s) thatenables the sending and receiving of information between the componentsof system 200. Network 260 may also comprise any combination of wiredand wireless networks. In other embodiments, one or more components ofsystem 200 can communicate directly through a dedicated communicationlink(s), such as links between provisioning entity analysis system 210,financial services system 220, geographic data systems 230, provisioningentity management systems 240, and consuming entity data systems 250.

As noted above, provisioning entity analysis system 210 can include adata fusion system (e.g., data fusion system 100) for organizing datareceived from one or more of the components of system 200.

FIG. 3 is a block diagram of an exemplary computer system 300,consistent with embodiments of the present disclosure. The components ofsystem 200 such as provisioning entity analysis system 210, financialservice systems 220, geographic data systems 230, provisioning entitymanagement systems 240, and consuming entity data systems 250 mayinclude the architecture based on or similar to that of computer system300.

As illustrated in FIG. 3, computer system 300 includes a bus 302 orother communication mechanism for communicating information, and one ormore hardware processors 304 (denoted as processor 304 for purposes ofsimplicity) coupled with bus 302 for processing information. Hardwareprocessor 304 can be, for example, one or more general-purposemicroprocessors or it can be a reduced instruction set of one or moremicroprocessors.

Computer system 300 also includes a main memory 306, such as a randomaccess memory (RAM) or other dynamic storage device, coupled to bus 302for storing information and instructions to be executed by processor304. Main memory 306 also can be used for storing temporary variables orother intermediate information during execution of instructions to beexecuted by processor 304. Such instructions, after being stored innon-transitory storage media accessible to processor 304, rendercomputer system 300 into a special-purpose machine that is customized toperform the operations specified in the instructions.

Computer system 300 further includes a read only memory (ROM) 308 orother static storage device coupled to bus 302 for storing staticinformation and instructions for processor 304. A storage device 310,such as a magnetic disk, optical disk, or USB thumb drive (Flash drive),etc. is provided and coupled to bus 302 for storing information andinstructions.

Computer system 300 can be coupled via bus 302 to a display 312, such asa cathode ray tube (CRT), liquid crystal display, or touch screen, fordisplaying information to a computer user. An input device 314,including alphanumeric and other keys, is coupled to bus 302 forcommunicating information and command selections to processor 304.Another type of user input device is cursor control 316, such as amouse, a trackball, or cursor direction keys for communicating directioninformation and command selections to processor 304 and for controllingcursor movement on display 312. The input device typically has twodegrees of freedom in two axes, a first axis (for example, x) and asecond axis (for example, y), that allows the device to specifypositions in a plane. In some embodiments, the same directioninformation and command selections as cursor control can be implementedvia receiving touches on a touch screen without a cursor.

Computing system 300 can include a user interface module to implement agraphical user interface that can be stored in a mass storage device asexecutable software codes that are executed by the one or more computingdevices. This and other modules can include, by way of example,components, such as software components, object-oriented softwarecomponents, class components and task components, processes, functions,attributes, procedures, subroutines, segments of program code, drivers,firmware, microcode, circuitry, data, databases, data structures,tables, arrays, and variables.

In general, the word “module,” as used herein, refers to logic embodiedin hardware or firmware, or to a collection of software instructions,possibly having entry and exit points, written in a programminglanguage, such as, for example, Java, Lua, C or C++. A software modulecan be compiled and linked into an executable program, installed in adynamic link library, or written in an interpreted programming languagesuch as, for example, BASIC, Perl, or Python. It will be appreciatedthat software modules can be callable from other modules or fromthemselves, and/or can be invoked in response to detected events orinterrupts. Software modules configured for execution on computingdevices can be provided on a computer readable medium, such as a compactdisc, digital video disc, flash drive, magnetic disc, or any othertangible medium, or as a digital download (and can be originally storedin a compressed or installable format that requires installation,decompression, or decryption prior to execution). Such software code canbe stored, partially or fully, on a memory device of the executingcomputing device, for execution by the computing device. Softwareinstructions can be embedded in firmware, such as an EPROM. It will befurther appreciated that hardware modules can be comprised of connectedlogic units, such as gates and flip-flops, and/or can be comprised ofprogrammable units, such as programmable gate arrays or processors. Themodules or computing device functionality described herein arepreferably implemented as software modules, but can be represented inhardware or firmware. Generally, the modules described herein refer tological modules that can be combined with other modules or divided intosub-modules despite their physical organization or storage.

Computer system 300 can implement the techniques described herein usingcustomized hard-wired logic, one or more ASICs or FPGAs, firmware and/orprogram logic which in combination with the computer system causes orprograms computer system 300 to be a special-purpose machine. Accordingto some embodiments, the operations, functionalities, and techniques andother features described herein are performed by computer system 300 inresponse to processor 304 executing one or more sequences of one or moreinstructions contained in main memory 306. Such instructions can be readinto main memory 306 from another storage medium, such as storage device310. Execution of the sequences of instructions contained in main memory306 causes processor 304 to perform the process steps described herein.In alternative embodiments, hard-wired circuitry can be used in place ofor in combination with software instructions.

The term “non-transitory media” as used herein refers to anynon-transitory media storing data and/or instructions that cause amachine to operate in a specific fashion. Such non-transitory media cancomprise non-volatile media and/or volatile media. Non-volatile mediacan include, for example, optical or magnetic disks, such as storagedevice 310. Volatile media can include dynamic memory, such as mainmemory 306. Common forms of non-transitory media can include, forexample, a floppy disk, a flexible disk, hard disk, solid state drive,magnetic tape, or any other magnetic data storage medium, a CD-ROM, anyother optical data storage medium, any physical medium with patterns ofholes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memorychip or cartridge, and networked versions of the same.

Non-transitory media is distinct from, but can be used in conjunctionwith, transmission media. Transmission media can participate intransferring information between storage media. For example,transmission media can include coaxial cables, copper wire and fiberoptics, including the wires that comprise bus 302. Transmission mediacan also take the form of acoustic or light waves, such as thosegenerated during radio-wave and infra-red data communications.

Various forms of media can be involved in carrying one or more sequencesof one or more instructions to processor 304 for execution. For example,the instructions can initially be carried on a magnetic disk or solidstate drive of a remote computer. The remote computer can load theinstructions into its dynamic memory and send the instructions over atelephone line using a modem. A modem local to computer system 300 canreceive the data on the telephone line and use an infra-red transmitterto convert the data to an infra-red signal. An infra-red detector canreceive the data carried in the infra-red signal and appropriatecircuitry can place the data on bus 302. Bus 302 carries the data tomain memory 306, from which processor 304 retrieves and executes theinstructions. The instructions received by main memory 306 canoptionally be stored on storage device 310 either before or afterexecution by processor 304.

Computer system 300 can also include a communication interface 318coupled to bus 302. Communication interface 318 can provide a two-waydata communication coupling to a network link 320 that can be connectedto a local network 322. For example, communication interface 318 can bean integrated services digital network (ISDN) card, cable modem,satellite modem, or a modem to provide a data communication connectionto a corresponding type of telephone line. As another example,communication interface 318 can be a local area network (LAN) card toprovide a data communication connection to a compatible LAN. Wirelesslinks can also be implemented. In any such implementation, communicationinterface 318 can send and receives electrical, electromagnetic oroptical signals that carry digital data streams representing varioustypes of information.

Network link 320 can typically provide data communication through one ormore networks to other data devices. For example, network link 320 canprovide a connection through local network 322 to a host computer 324 orto data equipment operated by an Internet Service Provider (ISP) 326.ISP 326 in turn can provide data communication services through theworld wide packet data communication network now commonly referred to asthe “Internet” 328. Local network 322 and Internet 328 can both useelectrical, electromagnetic or optical signals that carry digital datastreams. The signals through the various networks and the signals onnetwork link 320 and through communication interface 318, which carrythe digital data to and from computer system 300, can be example formsof transmission media.

Computer system 300 can send messages and receive data, includingprogram code, through the network(s), network link 320 and communicationinterface 318. In the Internet example, a server 330 can transmit arequested code for an application program through Internet 328, ISP 326,local network 322 and communication interface 318. The received code canbe executed by processor 304 as it is received, and/or stored in storagedevice 310, or other non-volatile storage for later execution. In someembodiments, server 330 can provide information for being displayed on adisplay.

FIG. 4 is a block diagram of an exemplary data structure 400, consistentwith embodiments of the present disclosure. Data structure 400 can storedata records associated with interactions involving multiple entities.Data structure 400 can be, for example, a database (e.g., database 170)that can store elements of an object model (e.g., object model 160). Insome embodiments, data structure 400 can be a Relational DatabaseManagement System (RDBMS) that stores interaction data as sections ofrows of data in relational tables. An RDBMS can be designed toefficiently return data for an entire row, or record, in as fewoperations as possible. An RDBMS can store data by serializing each rowof data of data structure 400. For example, in an RDBMS, data associatedwith interaction 1 of FIG. 4 can be stored serially such that dataassociated with all categories of interaction 1 can be accessed in oneoperation.

Alternatively, data structure 400 can be a column-oriented databasemanagement system that stores data as sections of columns of data ratherthan rows of data. This column-oriented DBMS can have advantages, forexample, for data warehouses, customer relationship management systems,and library card catalogs, and other ad hoc inquiry systems whereaggregates are computed over large numbers of similar data items. Acolumn-oriented DBMS can be more efficient than an RDBMS when anaggregate needs to be computed over many rows but only for a notablysmaller subset of all columns of data, because reading that smallersubset of data can be faster than reading all data. A column-orientedDBMS can be designed to efficiently return data for an entire column, inas few operations as possible. A column-oriented DBMS can store data byserializing each column of data of data structure 400. For example, in acolumn-oriented DBMS, data associated with a category (e.g., consumingentity identification category 420) can be stored serially such thatdata associated with that category for all interactions of datastructure 400 can be accessed in one operation.

As shown in FIG. 4, data structure 400 can comprise data associated witha very large number of interactions associated with multiple entities.For example, data structure 400 can include 50 billion interactions. Insome embodiments, interactions associated with multiple entities can bereferred to as transactions between multiple entities. Whereappropriate, the terms interactions and transactions are intended toconvey the same meaning and can be used interchangeably throughout thisdisclosure. While each interaction of data structure 400 is depicted asa separate row in FIG. 4, it will be understood that each suchinteraction can be represented by a column or any other known techniquein the art. Each interaction data can include several categories ofinformation. For example, the several categories can include, numbercategory 410; consuming entity identification category 420; consumingentity location category 430; provisioning entity identificationcategory 440; provisioning entity location category 450; type ofprovisioning entity category 460; interaction amount category 470; andtime of interaction category 480. It will be understood that FIG. 4 ismerely exemplary and that data structure 400 can include even morecategories of information associated with an interaction.

Number category 410 can uniquely identify each interaction of datastructure 400. For example, data structure 400 depicts 50 billioninteractions as illustrated by number category 410 of the last row ofdata structure 400 as 50,000,000,000. In FIG. 4, each row depicting ainteraction can be identified by an element number. For example,interaction number 1 can be identified by element 401; interactionnumber 2 can be identified by element 402; and so on such thatinteraction 50,000,000,000 can be identified by 499B. It will beunderstood that this disclosure is not limited to any number ofinteractions and further that this disclosure can extend to a datastructure with more or fewer than 50 billion interactions. It is alsoappreciated that number category 410 need not exist in data structure400.

Consuming entity identification category 420 can identify a consumingentity. In some embodiments, consuming entity identification category420 can represent a name (e.g., User 1 for interaction 401; User N forinteraction 499B) of the consuming entity. Alternatively, consumingentity identification category 420 can represent a code uniquelyidentifying the consuming entity (e.g., CE002 for interaction 402). Forexample, the identifiers under the consuming entity identificationcategory 420 can be a credit card number that can identify a person or afamily, a social security number that can identify a person, a phonenumber or a MAC address associated with a cell phone of a user orfamily, or any other identifier.

Consuming entity location category 430 can represent a locationinformation of the consuming entity. In some embodiments, consumingentity location category 430 can represent the location information byproviding at least one of: a state of residence (e.g., statesub-category 432; California for element 401; unknown for interaction405) of the consuming entity; a city of residence (e.g., citysub-category 434; Palo Alto for interaction 401; unknown for interaction405) of the consuming entity; a zip code of residence (e.g., zip codesub-category 436; 94304 for interaction 401; unknown for interaction405) of the consuming entity; and a street address of residence (e.g.,street address sub-category 438; 123 Main St. for interaction 401;unknown for interaction 405) of the consuming entity.

Provisioning entity identification category 440 can identify aprovisioning entity (e.g., a merchant or a coffee shop). In someembodiments, provisioning entity identification category 440 canrepresent a name of the provisioning entity (e.g., Merchant 2 forinteraction 402). Alternatively, provisioning entity identificationcategory 440 can represent a code uniquely identifying the provisioningentity (e.g., PE001 for interaction 401). Provisioning entity locationcategory 450 can represent a location information of the provisioningentity. In some embodiments, provisioning entity location category 450can represent the location information by providing at least one of: astate where the provisioning entity is located (e.g., state sub-category452; California for interaction 401; unknown for interaction 402); acity where the provisioning entity is located (e.g., city sub-category454; Palo Alto for interaction 401; unknown for interaction 402); a zipcode where the provisioning entity is located (e.g., zip codesub-category 456; 94304 for interaction 401; unknown for interaction402); and a street address where the provisioning entity is located(e.g., street address sub-category 458; 234 University Ave. forinteraction 401; unknown for interaction 402).

Type of provisioning entity category 460 can identify a type of theprovisioning entity involved in each interaction. In some embodiments,type of provisioning entity category 460 of the provisioning entity canbe identified by a category name customarily used in the industry (e.g.,Gas Station for interaction 401) or by an identification code that canidentify a type of the provisioning entity (e.g., TPE123 for interaction403). Alternatively, type of the provisioning entity category 460 caninclude a merchant category code (“MCC”) used by credit card companiesto identify any business that accepts one of their credit cards as aform of payment. For example, MCC can be a four-digit number assigned toa business by credit card companies (e.g., American Express™,MasterCard™, VISA™) when the business first starts accepting one oftheir credit cards as a form of payment.

In some embodiments, type of provisioning entity category 460 canfurther include a sub-category (not shown in FIG. 4), for example, typeof provisioning entity sub-category 461 that can further identify aparticular sub-category of provisioning entity. For example, aninteraction can comprise a type of provisioning entity category 460 as ahotel and type of provisioning entity sub-category 461 as either a bedand breakfast hotel or a transit hotel. It will be understood that theabove-described examples for type of provisioning entity category 460and type of provisioning entity sub-category 461 are non-limiting andthat data structure 400 can include other kinds of such categories andsub-categories associated with an interaction.

Interaction amount category 470 can represent a transaction amount(e.g., $74.56 for interaction 401) involved in each interaction. Time ofinteraction category 480 can represent a time at which the interactionwas executed. In some embodiments, time of interaction category 480 canbe represented by a date (e.g., date sub-category 482; Nov. 23, 2013,for interaction 401) and time of the day (e.g., time sub-category 484;10:32 AM local time for interaction 401). Time sub-category 484 can berepresented in either military time or some other format. Alternatively,time sub-category 484 can be represented with a local time zone ofeither provisioning entity location category 450 or consuming entitylocation category 430.

In some embodiments, each interaction data can include categories ofinformation including (not shown in FIG. 4), for example, consumingentity loyalty membership category, consuming entity credit card typecategory, consuming entity age category, consuming entity gendercategory, consuming entity income category, consuming entity withchildren category, product information category, and service informationcategory.

Consuming entity loyalty membership category can represent whether theconsuming entity is part of a loyalty membership program associated witha provisioning entity. For example, consuming entity loyalty membershipcategory can represent that the consuming entity is a member of one ofCostco™ membership programs including Goldstar Member™, ExecutiveMember™, and Business Member™. Consuming entity credit card typecategory can represent the type of credit card used by the consumingentity for a particular interaction. For example, consuming entitycredit card type category can represent that the credit card used by theconsuming entity for that particular interaction can be one eitherAmerican Express™, MasterCard™, VISA™, or Discover™ credit cards. Insome embodiments, consuming entity credit card type category canrepresent a kind of MasterCard™ (e.g., Gold MasterCard™ or PlatinumMasterCard™) used for a particular interaction.

In some embodiments, consuming entity demographic information can bestored in each interaction. For example, consuming entity demographicinformation can include at least one of: consuming entity age category,consuming entity gender category, consuming entity income category, andconsuming entity with children category. In some embodiments, consumingentity age category can represent age information associated with theconsuming entity; consuming entity gender category can represent genderinformation (e.g., Male or Female) associated with the consuming entity;consuming entity income category can represent income information (e.g.,greater than $100,000 per year) associated with the consuming entity;and consuming entity with children category can represent whether theconsuming entity has any children under 18 or not. For example, if theconsuming entity has children under 18, a positive indication can bestored and if the consuming entity does not has children under 18, anegative indication can be stored. In some embodiments, consuming entitywith children category can store information representing a number ofchildren associated with the consuming entity.

Product information category can represent information associated with aproduct that is involved in an interaction. For example, productinformation category can represent that the product involved in theinteraction is a particular type of product based on a stock keepingunit (“SKU”) of the product. In some embodiments, the product's SKU canbe unique to a particular provisioning entity involved in thatparticular interaction. Alternatively, product information category canrepresent the product involved in the interaction with a at least one ofa Universal Product Code, International Article Number, Global TradeItem Number, and Australian Product Number. Service information categorycan represent information associated with a service that is involved inan interaction. For example, service information category can representthat the service involved in the interaction is a particular type ofservice based on an SKU of the service. It will be appreciated that anSKU can uniquely represent either a product or a service. Some examplesof services can be warranties, delivery fees, installation fees, andlicenses.

FIG. 5 is a block diagram of an exemplary scenario depicting a systemfor analyzing entity performance, consistent with embodiments of thepresent disclosure. System 500 depicts a scenario where a consumingentity (e.g., user of cell phone 505) can attempt to access a service atone or more provisioning entities (e.g., Website 1 542, Website 2 544,and/or Website 3 546). To access one of the provisioning entities, theconsuming entity can initiate an access request from cell phone 505. Theaccess request can include a consuming entity identification such as,for example, a cell phone number or a MAC address associated with cellphone 505. The access request can then reach a cellular base station 515through a communication link 510. It will be understood thatcommunication link 510 can either be a wireless link (as shown in theexemplary embodiment of FIG. 5) or a wired link (not shown). Next, theaccess request can reach server 525 through network 520. Network 520 canbe, for example, the Internet. In some embodiments, network 520 can beone of either a local area network, a wide area network, or an entity'sintranet. Server 525 can be a server located at a service provider(e.g., Verizon Wireless™). Server 525 can be, in some embodiments, anauthentication, authorization, and accounting server (AAA server). Insome embodiments, server 525 can be a proxy server that can facilitate acommunication between cell phone 505 and a server device at theprovisioning entities (e.g., Website 1 542).

Access request can reach one of the provisioning entities after anauthorization, authentication, and accounting process is complete.Access request can traverse to one of the provisioning entities throughnetwork 530. Network 530 can be similar to network 520, as describedabove. After the authorized and authenticated access request reaches oneof the provisioning entities, the consuming entity is allowed to accessthe provisioning entities. In this exemplary embodiment, user of cellphone 505 can access either Website 1 542, Website 2 544, or Website 3546, depending on details of the access request. For example,provisioning entities can be one of the websites Google™, Facebook™, andTwitter™.

After a consuming entity (e.g., user of cell phone 505 or cell phone505) accesses one of the provisioning entities, server 525 can storeinformation regarding the user and/or cell phone accessing theseprovisioning entities. Each access by a user of a website can be storedas an interaction in a data structure in Server 525. Server 525 canstore such information in a data structure (e.g., data structure 400)comprising several categories of information including, but not limitedto, an interaction number; consuming entity identification; consumingentity location; provisioning entity identification; provisioning entitylocation; type of provisioning entity; duration of interaction; and timeof interaction. The data structure can be analyzed to analyze aperformance of provisioning entities, for example, to estimate a numberof unique consuming entities (e.g., users) per month, average amount oftime a consuming entity spends on their website, time of the day whereconsuming entity traffic is highest or lowest, etc. It will beunderstood that any number of useful insights can be drawn by analyzingthe data structure comprising interactions associated with consumingentities and provisioning entities. While FIG. 5, depicts a use casescenario of a cell phone user (exemplary consuming entity) accessing awebsite (exemplary provisioning entity), it will be understood that aprocess of analyzing interaction between a consuming entity and aprovisioning entity can be extended to any number of scenarios,including, financial transactions between consumers and banks; creditcard transactions between a consumer and a provisioning entity like agrocery store, movie theatre, gas station, mall, etc.

FIG. 6 depicts a flowchart representing an exemplary process foranalyzing entity performance, consistent with embodiments of the presentdisclosure. While the flowchart discloses the following steps in aparticular order, it will be appreciated that at least some of the stepscan be moved, modified, or deleted where appropriate, consistent withthe teachings of the present disclosure. The analyzing of the entityperformance can be performed in full or in part by a provisioning entityanalysis system (e.g., provisioning entity analysis system 210). It isappreciated that some of these steps can be performed in full or in partby other systems (e.g., such as those systems identified above in FIG.2).

In step 610, a request having one or more filter selections can bereceived at a provisioning entity analysis system implementing a processfor analyzing a performance of one or more entities of multipleentities. In some embodiments, the request can be received from aprovisioning entity (e.g., a merchant like Lowes™), which can beinterested in analyzing its performance with regards the one or morefilter selections. In some embodiments, one or more filter selections ofthe received request can comprise a selection to represent dataassociated with at least one of: cohorts; demographics; geographic;time; and transactions. Alternatively, the one or more filter selectionscan comprise a selection to represent data associated with at least oneof: charts; histograms; maps; numbers; and time. In some embodiments,the one or more filter selections can comprise a selection to representdata associated with at least one of: a location information associatedwith the occurrence of an interaction; a location information associatedwith the consuming entity; a location information associated with theprovisioning entity; demographic information representing at least oneof: age, gender, income, and location associated with the consumingentity; an amount associated with an interaction; and a time associatedwith an interaction. An exemplary screenshot of a user interface withexemplary filter selections is shown in FIGS. 7 and 8, described below.

In some embodiments, the process for analyzing a performance of one ormore entities of multiple entities can be implemented without having toreceive one or more filter selections. Such a process can beimplemented, for example, by having the provisioning entity analysissystem (e.g., provisioning entity analysis system 210) comprise one ormore predetermined filter selections. These exemplary one or morepredetermined filter selections can include the same selections as theone or more filters (e.g., add new filter 705 shown in FIG. 7) that canbe selected by a user as described above. For example, the one or morepredetermined filter selections can comprise at least one of: cohorts;demographics; geographic; time; and transactions. In another exemplaryembodiment, the one or more predetermined filter selections can compriseat least one of: charts; histograms; maps; numbers; and time.

Next, in step 620, a data structure (e.g., data structure 400)comprising several categories of information showing interactionsassociated with multiple entities can be accessed. The data structurecan represent information associated with a very large number ofinteractions. In some embodiments, the data structure can representinformation for tens of billions of interactions (e.g., data structure400 depicting 50 billion interactions). The data structure can besimilar to the exemplary data structure 400 described in FIG. 4 above.In exemplary embodiments comprising one or more predetermined filterselections, accessing step 620 can be implemented in the same fashion asthat of the exemplary embodiments where one or more filter selectionscan be received from a user.

Next, in step 630, some categories of the several categories within thedata structure can be identified based on the one or more filterselections of the received request. The identified categories, forexample, can be one or more of the several categories of the datastructure (e.g., data structure 400). In some embodiments, there can bea mapping between the one or more filter selections and the severalcategories. For example, a filter selection for customer zip code can bemapped to consuming entity location category 430 and further to zip codesub-category 436. Another exemplary mapping can exist between a filterselection for gender and a category or a sub-category associated with agender of consuming entity (not shown in FIG. 4). It will be appreciatedthat the exemplary mapping techniques described above are merelyexemplary and other mapping techniques can be defined within the scopeof this disclosure. In some embodiments, one or more filter selectionscan include “demographics and customer zip code” selections, as depictedin FIG. 8. When the provisioning entity (e.g., a home improvement storesuch as Lowes™) is interested in analyzing its performance at aparticular location with respect to consuming entities (e.g., a consumerbuying home improvement products at Lowes™) that buy products at thelocation, the provisioning entity can select one or more filters such asdemographics 820 and further zip code 824 (associated with a zip coderepresenting location of consuming entity).

Based on the one or more filter selections, the provisioning entityanalysis system (e.g., provisioning entity analysis system 210) canidentify some categories of the data structure that are relevant foranalyzing the performance of the one or more entities (e.g.,provisioning entity) regarding customer demographics including alocation (e.g., zip code) of the consuming entities. In this example,the provisioning entity analysis system can identify categoriesassociated with a number of interaction (e.g., number category 410), anidentity of consuming entities (e.g., consuming entity identificationcategory 420), and a location of consuming entities (e.g., consumingentity location category 430 including at least zip code sub-category436). In some embodiments, consuming entity location category 430 can beidentified along with one or more categories of state sub-category 432,city sub-category 434, zip code sub-category 436, and street addresssub-category 438. In exemplary embodiments comprising one or morepredetermined filter selections, identifying step 630 can be implementedin the same fashion as that of the exemplary embodiments where one ormore filter selections can be received from a user.

Next, in step 640, information associated with the identified categoriescan be processed to analyze a performance of one or more entities of themultiple entities in accordance with the one or more filter selections.In some embodiments, a first entity of the one or more entities can be aprovisioning entity (e.g., a home improvement store such as Lowes™). Oneor more entities of the multiple entities can comprise one or moregroups of entities of the multiple entities. For example, a group ofentities can be defined such that the group of entities can have similarcharacteristics such as all grocery stores within a given zip code orall Safeway™ locations within a city (e.g., San Jose, Calif.). In someembodiments, a group of entities can include all entities associatedwith the same MCC (e.g., 5542 for Automated Fuel Dispensers at a GasStation) within a given zip code. Processing the identified categoriescan comprise creating a new data structure that is different from thedata structure of step 620, and comprising only the identifiedcategories of step 630 or one or more subsets of those categories.Alternatively, processing the identified categories can be performed onthe existing data structure of step 620 (e.g., data structure 400).

By way of example, when the one or more filter selections is“demographics and customer zip code,” the system can process informationthat is associated with identified categories based on the filterselections such as a number of interaction (e.g., number category 410),an identity of consuming entities (e.g., consuming entity identificationcategory 420), a location of consuming entities (e.g., consuming entitylocation category 430 including at least zip code sub-category 436), andcategories associated with consuming entity demographics includingconsuming entity age category, consuming entity gender category, andconsuming entity income category. In some embodiments, data associatedwith identified categories can be stored in either a row-orienteddatabase or a column-oriented database, as described above with respectto data structure 400. Processing information can involve performingstatistical analysis on data stored in the identified categories.Performing statistical analysis, for example, can include variouscomputations of data associated with identified categories. For example,if an identified category is interaction amount category 470, processinginformation can include performing an aggregate of the interactionamount to compute a total amount for all interactions associated withthe provisioning entity. It will be understood that processinginformation can include other examples of performing statisticalanalysis, including but not limited to, computing an average, mean,maximum, minimum, or standard deviation for a series of data.

In some embodiments, processing the information of the identifiedcategories can result in a multitude of useful insights regarding thebehavior of consuming entities. Some of such insights, for example, canrelate to the kinds of products bought by consuming entities, a locationwhere consuming entities buy the products, a time as to when consumingentities buy the products, the frequency with which consuming entitiesbuy the products, a location of residence of consuming entities,demographics information of consuming entities including their age andincome level. It will be understood that the above-listed insights aremerely exemplary and a number of other insights can be drawn within thescope and spirit of this disclosure.

In some embodiments, processing the information of the identifiedcategories can result in a multitude of useful insights regarding theperformance of provisioning entities. Some of such insights, forexample, can relate to the kinds of products being sold by provisioningentities, a location where provisioning entities sell the products, atime as to when provisioning entities sell the products, a performancecomparison between different locations of the same provisioning entity.It will be understood that the above-listed insights are merelyexemplary and a number of other insights can be drawn within the scopeand spirit of this disclosure. In exemplary embodiments comprising oneor more predetermined filter selections, processing step 640 can beimplemented in the same fashion as that of the exemplary embodimentswhere one or more filter selections can be received from a user.

In some embodiments, step 640 can process information of a datastructure that is updated in real-time. That is, processing ofinformation can occur on the data structure that comprises up-to-dateinteraction data at the time of an execution of step 640. Alternatively,step 640 can process information of a data structure that is not updatedin real-time. That is, processing of information can occur on the datastructure that does not comprise up-to-date interaction data at the timeof an execution of step 640. For example, processing of information canoccur on a data structure that is updated only periodically (e.g., on adaily or weekly basis) and not in real-time.

Next, in step 650, the processed information can be provided fordisplaying the performance of the one or more entities (e.g.,provisioning entity) on a user interface. In some embodiments, the userinterface can comprise a representation of a geographic region. The userinterface can also comprise a representation of locations of the one ormore entities overlaid on the geographic region; and further arepresentation of sub-geographic regions overlaid on a geographicregion. Alternatively, the user interface can include a representationof the performance of the one or more entities over geographic orsub-geographic regions associated with a location of the one or moreentities. For example, geographic or sub-geographic regions can beassociated with a location of either a consuming entity or aprovisioning entity.

In exemplary embodiments comprising one or more predetermined filterselections, providing step 650 can be implemented in the same fashion asthat of the exemplary embodiments where one or more filter selectionscan be received from a user. Exemplary user interfaces are depicted inFIGS. 7-9 that illustrate a performance of a provisioning entity basedon one or more filter selections. As shown in FIGS. 7-9, user interfacecan either be a graph-based, map-based, or any other related interface.

FIGS. 7-9 illustrate several exemplary user interfaces that can begenerated by provisioning entity analysis system, consistent withembodiments of the present disclosure. The exemplary user interfaces ofFIGS. 7-9 are meant to help illustrate and describe certain features ofdisclosed embodiments, and are not meant to limit the scope of the userinterfaces that can be generated or provided by the provisioning entityanalysis system.

FIG. 7 shows an exemplary user interface 700 generated by a provisioningentity analysis system (e.g., provisioning entity analysis system 210),according to some embodiments. User interface 700 includes an option toadd one or more new filters (e.g., add new filter 705). In someembodiments, a provisioning entity (or a user of a provisioning entity)can select the option to select the one or more new filters.Alternatively, a consuming entity can select the option to select theone or more filters. In some embodiments, the option to add one or morefilters can include adding filters associated with charts 710,histograms 720, maps 730, numbers 740, and time 750. Each of theabove-recited filters can further comprise sub-filters. For example,filter maps 730 can further comprise sub-filters associated withMap-Consuming Entity Source 732, Map-Provisioning Entity Revenue 734,and Regional Chart-Spend by Region 736. It will be understood that oneor more filters (and sub-filters) can include any other filtersassociated with interactions associated with multiple entities stored ina data structure (e.g., data structure 400).

User interface 700 can include map 760, which shows consuming entitysource and geohash regions (while shown as shaded rectangles, they canalso include any unshaded rectangles). A geohash region, or geohashbucket, is a region associated with a latitude/longitude, hierarchalgeocode system that subdivides regions of the Earth into grid shapedbuckets. The level of granularity of geohash regions can vary dependingon the length of the geohash code corresponding to that region. Forexample, a geohash code that is one bit in length can correspond to ageohash region of roughly 20 million square kilometers, and a geohashcode that is six bits in length can correspond to a geohash region ofroughly 1.2 square kilometers. In some embodiments, a geohash region offive bits (roughly 18 square kilometers) is preferred, although the sizeof the geohash region can depend on the character of the overall regionwhich is being geohashed. For example, a six bit geohash can be moresuitable for a densely populated urban area, while a four bit geohashcan be more suitable for a sparsely populated rural area. In someembodiments, location information of an entity can be represented by ageohash region. For example, a geohash region of five bits representingSan Jose, Calif., can comprise the latitude/longitude coordinates, N37.3394° W 121.8950°, and can be depicted as shaded region 775 asillustrated on map 770. Alternatively, location information can berepresented using a zip code. For example, a portion of San Jose,Calif., can be represented by using a zip code, 95113. It will beappreciated that location information can be represented in other wayssuch as street address, city, state, Global Positioning Satellitecoordinates, etc.

In some embodiments, after a user enters information into the add newfilter (e.g., add new filter 705), the provisioning entity analysissystem receives a message to regenerate or modify the user interface.For example, if a user entered Maps 730 and then Map-Consuming EntitySource 732 into the add new filter box, the provisioning entity analysissystem could receive a message indicating that a user interface shoulddisplay a map with a location of each consuming entity for the givenregion of the map (e.g., San Francisco Bay Area), and it can generate auser interface with map 760 showing a location information for eachconsuming entity. For example, map 760 can display consuming entitylocation as shaded and unshaded rectangles in geo-hash regions. In someembodiments, a region of the map can be selected by a user by using aninput device such as mouse, key board, or touch pad.

In some embodiments, after a user selects Maps 730 and thenMap-Provisioning Entity Revenue 734 into the add new filter box, theprovisioning entity analysis system could receive a message indicatingthat a user interface should display a map with revenue information ofprovisioning entity for the given region of the map (e.g., San FranciscoBay Area), and it can generate a user interface with map 770 showingrevenue information of provisioning entity over the given region of map.For example, map 770 displays provisioning entity revenue as shaded andunshaded rectangles in geo-hash regions. It will be understood that userinterface 700 can further comprise representations associated with otherfilter (and sub-filter) selections, including but not limited to, charts710, histograms 720, numbers 740, and time 750.

FIG. 8 shows an exemplary user interface 800 generated by a provisioningentity analysis system (e.g., provisioning entity analysis system 210),according to some embodiments. User interface 800 includes an option toadd one or more new filters (e.g., add new filter 805. In someembodiments, the option to add one or more filters can include addingfilters to display an entity's performance comprising either cohortanalysis (e.g., cohorts 810), demographic analysis (e.g., demographics820), geographic analysis (e.g., geographics 830), time-based analysis(e.g., time 840), and interaction analysis (e.g., interactions 850).Each of the above-recited filters can further comprise sub-filters. Forexample, filter demographics 820 can further comprise sub-filtersassociated with age of consuming entity (e.g., age 822), location ofconsuming entity (e.g., consuming entity zipcode 824), gender ofconsuming entity (e.g., gender 826), and income of consuming entity(e.g., income 828).

User interface 800 can include map 860, which can show, for example, arepresentation of income of consuming entities in terms of geohashregions (while shown as shaded rectangles, they can also include anyunshaded rectangles). In some embodiments, after a user entersinformation into the add new filter (e.g., add new filter 805), theprovisioning entity analysis system receives a message to regenerate ormodify the user interface. For example, if a user entered demographics820 and then income 828 into the add new filter box, the provisioningentity analysis system would receive a message indicating that a userinterface should display a map with income information of consumingentity for the given region of the map (e.g., San Francisco Bay Area),and it can generate a user interface with map 860 showing arepresentation of income information of consuming entity using geohashregions. For example, map 860 displays consuming entity income as shadedand unshaded rectangles in geo-hash regions. In some embodiments, if auser selects geograhics 830 and then revenue 828 (to display aprovisioning entity's revenue over the selected region) into the add newfilter box, the provisioning entity analysis system would receive arequest indicating that a user interface should display a map withrevenue information of provisioning entity revenue for the given regionof the map (e.g., San Francisco Bay Area), and it can generate a userinterface with map 870 showing a representation of revenue informationof provisioning entity revenue using geohash regions. For example, map870 displays provisioning entity revenue as shaded and unshadedrectangles in geo-hash regions.

FIG. 9 shows an exemplary user interface 900 generated by a provisioningentity analysis system (e.g., provisioning entity analysis system 210),according to some embodiments. In addition to map-based representation(e.g., map 910 and map 920), user interface 900 can also depict anentity performance as either a graph-based representation (e.g., graph930) or a heat-map representation (e.g., heat-map 940). In someembodiments, a user can select one or more filters (e.g., add new filter905) to display a timeline of an aggregate spending by consumingentities. In such exemplary scenarios, provisioning entity analysissystem (e.g., provisioning entity analysis system 210) can generate auser interface (e.g., graph 930) that can represent an aggregate ofconsuming entity spending on a daily basis at a given provisioningentity. Alternatively, the aggregate consuming entity spending on adaily basis can be displayed as a graph-based representation where theindependent axis (e.g., x-axis) can represent a day and the other axiscan represent aggregate consuming entity spending on a daily basis, asdepicted in graph 930.

In some embodiments, a user can select one or more filters (e.g., addnew filter 905) to display an hourly spending by consuming entities. Insuch exemplary scenarios, provisioning entity analysis system (e.g.,provisioning entity analysis system 210) can generate a user interface(e.g., heat map 940) that can represent consuming entity spending on anhourly basis at a given provisioning entity. Alternatively, theconsuming entity spending on an hourly basis can be displayed as aheat-map representation where different shades of gray-scale can be usedto show different amount of spending on an hourly basis. In someembodiments, a color coded heat-map can be used where different colorscan be used to show different amount of spending on an hourly basis.While FIG. 9 depicts a few representations of entity performance, itwill be understood that those representations are merely exemplary andother representations are possible within the spirit and scope of thisdisclosure.

FIG. 10A depicts a flowchart representing an exemplary process foranalyzing entity performance, consistent with embodiments of the presentdisclosure. While the flowchart discloses the following steps in aparticular order, it will be appreciated that at least some of the stepscan be moved, modified, or deleted where appropriate, consistent withthe teachings of the present disclosure. The analyzing of the entityperformance can be performed in full or in part by a provisioning entityanalysis system (e.g., provisioning entity analysis system 210). It isappreciated that some of these steps can be performed in full or in partby other systems (e.g., such as those systems identified above in FIG.2).

In step 1010A, an identifier associated with an entity can berecognized. In some embodiments, the entity can be a provisioningentity. Alternatively, the entity can be a consuming entity. In someembodiments, the identifier can be information associated with aprovisioning entity identification category. Alternatively, theidentifier can be information associated with a consuming entityidentification category. It will be appreciated that other methods forrecognizing an identifier associated with an entity are possible.

Next, in step 1020A, a data structure (e.g., data structure 400)comprising several categories of information and one or moreinteractions associated with a plurality of entities can be accessed.The data structure can represent information associated with a verylarge number of interactions. In some embodiments, the data structurecan represent information for tens of billions of interactions (e.g.,data structure 400 depicting 50 billion interactions). The datastructure can be similar to the exemplary data structure 400 describedin FIG. 4 above.

Next, in step 1030A, one or more interactions of the plurality ofinteractions can be identified based on the recognized identifier. Insome embodiments, the identified interactions can be one or moreinteractions of the data structure that are associated with therecognized identifier of the entity. For example, the identifiedinteractions can be one or more interactions associated with aprovisioning entity identification information (e.g., provisioningentity identification category 440) or a consuming entity identificationinformation category (e.g., consuming entity identification category420). For an exemplary provisioning entity identification information of“Merchant 1,” step 1030 can identify one or more interactions that areassociated with a provisioning entity that can be identified with a nameor code “Merchant 1.”

In some embodiments, the accessed data structure can comprise severalcategories of information showing interactions associated with multipleentities. In such embodiments, the provisioning entity analysis system(e.g., provisioning entity analysis system 210) can identify somecategories of the data structure that are relevant for analyzing theperformance of the entity (e.g., provisioning entity) associated withthe recognized identifier.

Next, in step 1040A, information associated with the identifiedinteractions can be processed to analyze a performance of the entity. Insome embodiments, processing the identified interactions can comprisecreating a new data structure that is different from the data structureof step 1020A, and can comprise only the identified interactions of step1030A or one or more subsets of those categories. Alternatively,processing the identified interactions is performed on the existing datastructure of step 1020A (e.g., data structure 400).

In some embodiments, processing the information of the identifiedinteractions can result in a multitude of useful insights regarding thebehavior of consuming entities. Some of such insights, for example, canrelate to the kinds of products bought by consuming entities, a locationwhere consuming entities buy the products, a time as to when consumingentities buy the products, the frequency with which consuming entitiesbuy the products, a location of residence of consuming entities,demographics information of consuming entities including their age andincome level. It will be understood that the above-listed insights aremerely exemplary and a number of other insights can be drawn within thescope and spirit of this disclosure.

Alternatively, processing the information of the identified interactionscan result in a multitude of useful insights regarding the performanceof provisioning entities. Some of such insights, for example, can relateto the kinds of products being sold by provisioning entities, a locationwhere provisioning entities sell the products, a time as to whenprovisioning entities sell the products, a performance comparisonbetween different locations of the same provisioning entity, andperformance comparison between competing provisioning entities. It willbe understood that the above-listed insights are merely exemplary and anumber of other insights can be drawn within the scope and spirit ofthis disclosure.

In some embodiments, step 1040A can process information of a datastructure that is updated in real-time. That is, processing ofinformation can occur on the data structure that comprises up-to-dateinteraction data at the time of an execution of step 1040A.Alternatively, step 1040A can process information of a data structurethat is not updated in real-time. That is, processing of information canoccur on the data structure that does not comprise up-to-dateinteraction data at the time of an execution of step 1040A. For example,processing of information can occur on a data structure that is updatedonly periodically (e.g., on a daily or weekly basis) and not inreal-time.

In some embodiments, the processed information can comprise analysisinformation of a first entity or a first group of entities of theplurality of entities and a second entity or a second group of entitiesof a plurality of entities. For example, a first entity of the one ormore entities can be a provisioning entity (e.g., a home improvementstore such as Lowes™) and a second entity of the one or more entitiescan be a provisioning entity (e.g., a home improvement store such asHome Depot™). In some embodiments, the second entity can be a competitorof the first entity. In some embodiments, the first or second group ofentities of the plurality of entities can be defined such that the firstor second group of entities can comprise similar characteristics. Forexample, the first or second group of entities can be all grocery storeswithin a given zip code or all Safeway™ locations within a city (e.g.,San Jose, Calif.). Alternatively, the first or second group of entitiescan include all entities associated with the same MCC (e.g., 5542 forAutomated Fuel Dispensers at a Gas Station) within a given zip code.

In some embodiments, for each entity of a plurality of entities, a groupof entities (e.g., a first group of entities of the plurality ofentities) associated with the entity can be identified or estimated suchthat the entity can analyze its own performance against the group ofentities in aggregate. The group of entities can include a group ofprovisioning entities. For example, the group of provisioning entitiesassociated with a first provisioning entity can be identified based onat least one of: a similarity between attributes of consuming entitiesthat are associated with the first provisioning entity and consumingentities that are associated with other provisioning entities; alocation information associated with the first provisioning entity andassociated with other provisioning entities; information representing amarket share associated with the first provisioning entity and a marketshare associated with the other provisioning entities; and informationrepresenting a wallet share associated with the first provisioningentity and a wallet share associated with the other provisioningentities. In some embodiments, the group of entities can be referred toas, for example, a cohort of entities, a set of entities, or anassociated set of entities. It will be appreciated that the group ofentities can be referred to by using other names.

A similarity between attributes of consuming entities that areassociated with the first provisioning entity and consuming entitiesthat are associated with other provisioning entities can be used todetermine a group of provisioning entities associated with the firstprovisioning entity. For example, customer entity demographicinformation (e.g., age, gender, income, and/or location) can be analyzedbetween customer entities of the first provisioning entity and customerentities of the other provisioning entities to identify a group ofprovisioning entities that have similar customer entity demographicinformation. Location information associated with the first provisioningentity and with other provisioning entities can be analyzed to identifya group of provisioning entities associated with the first provisioningentity. For example, other provisioning entities that are located withina specified distance to a location of the first provisioning entity canbe identified as part of the group of provisioning entities.Alternatively, other distance criteria such as, for example, same zipcode, can be used to identify the group of provisioning entities. Forexample, a restaurant situated in an airport can be interested inanalyzing its own performance relative to other restaurants situatedwithin the same airport.

Information representing a market share associated with the firstprovisioning entity and a market share associated with the otherprovisioning entities can be used to identify a group of provisioningentities associated with the first provisioning entity. For example, ahigh-end bicycle store can be interested in comparing its performanceagainst other high-end bicycle stores. In other words, a group ofhigh-end bicycle stores can be identified based on a market shareanalysis of high-end bicycle stores. Information representing a walletshare associated with the first provisioning entity and a wallet shareassociated with the other provisioning entities can be used to identifya group of provisioning entities associated with the first provisioningentity. For example, a novelty late-night theatre can be interested incomparing its performance against other provisioning entities that alsooperate late-night (e.g., bars or clubs) and hence can likely competewith those entities for a consuming entity's time and money. Anexemplary definition of wallet share can be a percentage of consumingentity spending over a period of time such as on a daily basis or aweekly basis etc.

In some embodiments, the group of provisioning entities can beidentified by using a multi-timescale correlation comparison. One methodof implementing the multi-timescale correlation comparison can be byanalyzing interactions between a consuming entity and a firstprovisioning entity (“first provisioning entity interactions”) with thatof interactions between the consuming entity and a second provisioningentity (“second provisioning entity interactions”). For example, if thefirst provisioning entity interactions are correlated with the secondprovisioning entity interactions on a daily timescale butanti-correlated (or inversely correlated) on an hourly timescale, thenthe first provisioning entity and the second provisioning entity can bedefined as complementary entities rather than competitive entities. Insuch scenarios, the second provisioning entity need not be part of agroup of provisioning entities the first provisioning entity isinterested in comparing against. Alternatively, if the firstprovisioning entity interactions are anti-correlated with the secondprovisioning entity interactions on a daily timescale but correlated onan hourly timescale, then the first provisioning entity and the secondprovisioning entity can be defined as competitive entities. In suchscenarios, the second provisioning entity can be included in a group ofprovisioning entities the first provisioning entity is interested incomparing against.

In some embodiments, a competitor to the first entity can be identifiedor estimated based on at least one of: an MCC information associatedwith the first entity; a distance between a location of the first entityand a location of the competitor; and demographic informationrepresenting at least one of age, income, and gender associated with aconsuming entity involved in interactions associated with the firstentity.

In some embodiments, an identity of the first entity can be known and anidentity of the second entity can be unknown. For example, therecognized identifier can be associated with the first entity andaccordingly, an identify of the first entity can be known. In suchembodiments, an identity of the second entity can be estimated based oninformation representing at least two attributes of the first entity. Insome embodiments, the at least two attributes of the first entity caninclude an attribute representing a type of entity for the firstidentity and an attribute representing a location of the first entity.For example, knowing a type of the first entity (e.g., gas station) andlocation of the first entity (e.g., zip code), the data structure (e.g.,data structure 400) can be analyzed to identify entities that are of thesame type as that of the first entity and are in a proximity to thelocation of the first entity. If the estimation returns more than onepossible choice for an identity of the second entity, the system canselect one of the possible choices by selecting the entity that isclosest in proximity to the first entity. Alternatively, other criteriacan be used to select from the more than one possible choices. In someembodiments, attributes other than that of location and type of thefirst entity can be used to estimate the identity of the second entity.

Next, in step 1050A, the processed information can be provided fordisplaying the performance of the entity (e.g., provisioning entity) ona user interface. In some embodiments, the user interface can comprise arepresentation of a geographic region. The user interface can alsocomprise a representation of locations of the one or more entitiesoverlaid on the geographic region; and further a representation ofsub-geographic regions overlaid on a geographic region. An exemplaryuser interface is depicted in FIG. 10B. As shown in FIG. 10B, the userinterface can include a dashboard showing a graphical representation ofthe performance of an entity based on recognizing an identifier for theentity.

More particularly, FIG. 10B shows an exemplary user interface 1000B thata provisioning entity analysis system (e.g., provisioning entityanalysis system 210) can generate, according to some embodiments. Userinterface 1000B can include a dashboard (e.g., dashboard 1010B) that candepict a performance of an entity over a metric. For example, dashboard1010B represents information of sales of the entity (e.g., aprovisioning entity) over a 7-day period for the current week (May 25,2013-May 31, 2013) compared to the same week of the previous year (May25, 2012-May 31, 2012). In some embodiments, dashboard 1010B canrepresent information comparing the entity's actual revenue with theentity's expected revenue. For example, the provisioning entity caninput an expected revenue for a period of time (e.g., weekly, quarterly,or yearly). After receiving information regarding the expected revenue,the provisioning entity analysis system can analyze interaction data toanalyze the entity's performance relative to the expected revenue. Anoutcome of such comparative analysis can be represented with anexemplary bar graph or a pie chart on user interface 1000B.Alternatively, the entity's expected revenue information can be inferredwithout having to receive an external input representing the expectedrevenue. For example, the provisioning analysis system can analyzeinteraction data of the data structure to estimate a number for theentity's expected revenue.

In some embodiments, dashboard 1010B can be represented as a bar graphusing two different fills, one fill representing sales of the currentweek and another representing sales from last year. It will beunderstood that other representations of dashboard 1010A are possible.Alternatively, the dashboard can be preconfigured to analyze interactiondata for a period of time such as, for example, 7-days, one month, onequarter, one year, etc.

In some embodiments, user interface 1000B can also include a box forrepresenting an alert (e.g., latest alert 1020B) that can indicatecertain performance metrics of the entity. For example, latest alert1020B includes information to indicate that the entity's worst daywithin the preconfigured period of time is May 31, 2013. A differententity performance metric can be included in latest alert 1020B.Alternatively, user interface 1000B can include user interface elementsrepresenting information associated with entity performance metrics suchas revenue (e.g, revenue 1025B), amount of interaction (e.g., ticketsize 1030B), new consuming entities (new consuming entities 1035B),returning consuming entities (e.g., returning consuming entities 1040B),time of interaction in a day (e.g., time of day 1045B), and interactionsduring a day of the week (e.g., day of week 1050B). For example, each ofthe above-described user interface elements can be depicted asrectangular box with an icon and some information representing theperformance metric of the entity. It will be understood that in someembodiments, user interface elements can be depicted using differentapproaches such as, for example, charts, maps, histograms, numbers etc.

FIG. 11 depicts a flowchart representing an exemplary process forcomparing entity performance, consistent with embodiments of the presentdisclosure. While the flowchart discloses the following steps in aparticular order, it will be appreciated that at least some of the stepscan be moved, modified, or deleted where appropriate, consistent withthe teachings of the present disclosure. The comparing of the entityperformance can be performed in full or in part by a provisioning entityanalysis system (e.g., provisioning entity analysis system 210). It isappreciated that some of these steps can be performed in full or in partby other systems (e.g., such as those systems identified above in FIG.2).

In step 1110, an input for at least one category of information to becompared between a first entity and a second entity can be received at aprovisioning entity analysis system implementing a process for comparinga performance between the first entity and a second entity. In someembodiments, the input can be received from a provisioning entity (e.g.,a merchant like Lowes™), which can be interested in analyzing theirperformance relative to a competitor (e.g., HomeDepot™) Alternatively, acompetitor to the first entity can be identified or estimated based onat least one of: an MCC information associated with the first entity; adistance between a location of the first entity and a location of thecompetitor; and demographic information representing at least one ofage, income, and gender associated with a consuming entity involved ininteractions associated with the first entity.

In some embodiments, the input can be received from a first entity,where an identity of the first entity can be known. In some embodiments,an identity of the second entity can be provided. For example, the userof the first entity can provide an identity of the second entity.Alternatively, an identity of the second entity is not provided. Inexemplary embodiments where an identity of the second entity is notprovided, an identity of the second entity can be estimated as describedbelow.

In some embodiments, the received input can comprise a selection torepresent data associated with at least one of: demographics;geographic; time; and transactions. Alternatively, the received inputcan comprise a selection to represent data associated with at least oneof: charts; histograms; maps; numbers; and time. In some embodiments,the received input can be similar to one or more filter selections(e.g., add new filter 705) described in FIG. 6. An exemplary screenshotof a user interface comparing a performance of the first entity withthat of the second entity can be shown in FIG. 12, described below.

Next, in step 1120, a data structure (e.g., data structure 400)comprising several categories of information showing interactionsassociated with multiple entities can be accessed. The data structurecan represent information associated with a very large number ofinteractions (e.g., data structure 400 of FIG. 4. depicting 50 billioninteractions). In some embodiments, the multiple entities can include atleast the first entity (e.g., a first provisioning entity such asLowes™) and the second entity (e.g., a second provisioning entity suchas HomeDepot™)

Next, in step 1130, an identity of the second entity can be estimatedbased on information representing at least two attributes of the firstentity. In some embodiments, the at least two attributes of the firstentity can include an attribute representing a type of entity for thefirst identity and an attribute representing a location of the firstentity. For example, knowing a type of the first entity (e.g., gasstation) and location of the first entity (e.g., zip code), the datastructure (e.g., data structure 400) can be analyzed to identifyentities that are of the same type as that of the first entity and arein a proximity to the location of the first entity. If the estimationreturns more than one possible choice for an identity of the secondentity, the system can select one of the possible choices by selectingthe entity that is closest in proximity to the first entity.Alternatively, other criteria including, attributes other than that oflocation and type of the first entity can be used to estimate theidentity of the second entity.

Next, in step 1140, relevant interaction information associated with theat least one category of the data structure can be processed to comparea performance of the first entity with that of the second entity. Insome embodiments, the processing step 1140 can be very similar toprocessing step 640 described above. For example, step 1140 can involvetwo processing operations (e.g., processing operation of step 640), onefor processing the information associated with the at least one categoryof the first entity and another one for processing the informationassociated with the at least one category of the second entity. Afterperforming such operations, step 1140 can then compare the processedinformation from processing the first entity with that of the secondentity.

Next, in step 1150, the processed information can be provided fordisplaying a comparison between a performance of the first entity withthat of the second entity. Exemplary user interface is depicted in FIG.12 that illustrates a performance comparison between the first andsecond entities.

FIG. 12 shows a user interface 1200 generated by a provisioning entityanalysis system (e.g., provisioning entity analysis system 210),according to some embodiments. In some embodiments, user interface 1200includes an option to add one or more inputs for categories to becompared between entities. For example, user interface 1200 can includecategories representing timeline 1211, revenue 1212, total transactions1213, ticket size 1214, and time/day 1215. It will be understood thatother categories can be included in user interface 1200.

User interface 1200 can depict two graphs (e.g., graph 1252 and graph1262) to represent a performance comparison between the first entity andthe second entity. For example, graph 1252 can represent a performanceof the first entity for the selected category revenue 1212. In theexemplary embodiment depicted in user interface 1200, the first entityintends to compare its own revenue performance with that of one of itscompetitor over a given period of time (e.g., over the current quarter).Graph 1252 can represent revenue of the first entity over the currentquarter whereas graph 1262 can represent revenue of the second entity(competitor to the first entity) over the same current quarter. It willbe understood that in some embodiments, entity performance can berepresented using different approaches such as, for example, charts,maps, histograms, numbers etc. In some embodiments, where an identity ofthe second entity is not known, an identity of the second entity can beestimated using the exemplary process described in FIG. 11.

FIG. 13 depicts a flowchart representing an exemplary process 1300 forestimating a location of a consuming entity, consistent with embodimentsof the present disclosure. While the flowchart discloses the followingsteps in a particular order, it will be appreciated that at least someof the steps can be moved, modified, or deleted where appropriate,consistent with the teachings of the present disclosure. Process 1300can be performed in full or in part by a provisioning entity analysissystem (e.g., provisioning entity analysis system 210). It isappreciated that some of these steps can be performed in full or in partby other systems (e.g., such as those systems identified above in FIG.2).

In step 1310, a data structure (e.g., data structure 400) comprising aplurality of interactions associated with multiple entities can beaccessed. In some embodiments, the accessed data structure can comprisea plurality of categories of information showing interactions associatedwith multiple entities. The data structure can be similar to theexemplary data structure 400 described with reference to FIG. 4 above.The plurality of interactions of the data structure can includeinformation associated with a consuming entity and a provisioning entity(e.g., a first provisioning entity). Each such interaction of the datastructure can include at least one attribute of the consuming entity andat least one attribute of the provisioning entity. In some embodiments,the at least one attribute of the consuming entity can include alocation information of the consuming entity. For some consumingentities, the location information may not be known or identified.

Moreover, in some embodiments, the at least one attribute of theprovisioning entity can include an identification information of theprovisioning entity. Alternatively, the at least one attribute of theprovisioning entity can include an attribute other than anidentification information of the provisioning entity, such as a type ofthe provisioning entity.

Next, in step 1320, an interaction of the data structure can beevaluated. Next, in step 1330, a determination can be made for theinteraction of the data structure as to whether the interaction includesan identified location information of the consuming entity. In someembodiments, the determination can include analyzing whether thecategories of information associated with a location information of theconsuming entity (e.g., consuming entity location category 430) arepopulated or not. If it turns out that the categories of informationassociated with a location information of the consuming entity arepopulated, then the determination can return a positive indication tosignify that the at least one attribute of the consuming entity includesa location information of the consuming entity and the process can thenmove to step 1360. If, on the other hand, the categories of informationassociated with a location information of the consuming entity are notpopulated, then the determination can return a negative indication tosignify that the interaction does not include a location information ofthe consuming entity and the process can then move to step 1340.

In some embodiments, where the categories of information associated witha location information of the consuming entity are populated, thedetermination can further include verifying that the populated data isvalid data that signifies a location information before the process canmove to step 1360. For example, for the category of informationrepresenting zip code (e.g., zip code sub-category 456), if thepopulated data is 94085, it can be verified as a valid data and theprocess can then move step 1360. On the other hand, if the populateddata is 940850, it can be verified as an invalid data for zip code aszip codes, at least in the United States, are supposed to be only fivedecimal numerical digits, and the process can then move to step 1340described below. It will be understood that other methods to determinewhether the interaction includes a location information of the consumingentity can be implemented within the scope and spirit of thisdisclosure.

Next, if the interaction of the data structure does not include anidentified location information of the consuming entity, at step 1340,an estimation can be performed to determine location information of theconsuming entity based on its interactions with one or more provisioningentities (e.g., second provisioning entity, for purposes of simplicity)of a particular type (e.g., type of provisioning entity category 460).For example, the second provisioning entity can be of the type includinga gas station, a pharmacy, restaurant, or a grocery store. In someembodiments, location information of the consuming entity can beestimated by analyzing interactions between the consuming entity and thesecond provisioning entity. For example, interactions between theconsumer entity and a type of provisioning entity that represents gasstations can be analyzed such that the gas station at which theconsuming entity most frequently fills up gas can be identified as alocation of the consuming entity. This is because it can be reasonableto assume that the consuming entity can frequently fill up gas at a gasstation that is in a proximity to the residential location of theconsuming entity. In some embodiments, interactions between the consumerentity and a type of provisioning entities that represent gas stationscan result in similar number of interactions between two different gasstations in two different locations (e.g., zip codes). In suchembodiments, one method of estimating a location of the consuming entityis to then analyze interactions between the consuming entity and a thirdprovisioning entity that can represent grocery stores because it can bereasonable to assume that the consuming entity would more often than notshop for groceries at a location closer to residential location of theconsuming entity. Moreover, in some embodiments, the estimating of alocation can take into consideration the date (e.g., weekend) and ortime (e.g., typical times before or after work) of an interaction with atype of provisioning entity. Based on analyzing interactions with thethird provisioning entity (such as grocery stores) and combining suchanalysis with that of the interactions with the second provisioningentity (such as gas stations), an estimation can be made regarding alocation of the consuming entity.

In some embodiments, step 1340 can estimate a location information ofthe consuming entity after the determination returns that the at leastone attribute of the consuming entity includes an invalid locationinformation of the consuming entity by using similar techniques asdescribed above. It will be understood that the above-recited estimationtechniques are merely exemplary and not intended to be limiting.

Next, in step 1350, the data structure can be updated with an estimatedlocation information of the consuming entity. In some embodiments, dataassociated with only the evaluated interaction can be updated.Alternatively, data associated with all interactions associated with theconsuming entity can be updated irrespective of whether thoseinteractions were previously evaluated or not. Next, in step 1360, adetermination can be made whether the data structure comprisesadditional interactions that are to be evaluated. If the determinationreturns an answer in the positive, signifying that there are additionalinteractions that are to be evaluated, the process can go back to step1320 to evaluate another interaction and further to repeat the processcomprising steps 1320 through 1360, as described above. On the otherhand, if the determination returns an answer in the negative, signifyingthat there are no additional interactions that are to be evaluated, theprocess can end.

In some embodiments, a provisioning entity analysis system can resolvethe name of a provisioning entity. A data structure storing informationassociated with billions of interactions can include millions ofprovisioning entities and it is possible that some of the names of theprovisioning entities are not consistent. For example, the name ofprovisioning entity “McDonalds's” can be indicated by a number ofcombinations such as, “McDonald's,” “Mc Donalds,” “mcdonalds,”“Mcdonald's,” etc. While each of the above-recited names can be intendedto indicate the same entity, some processing can be necessary before thesystem can analyze all such names as the same entity. Exemplary methodsfor resolving a name of provisioning entities are described in U.S.Non-Provisional patent application Ser. No. 13/827,491, titled ResolvingSimilar Entities From A Transaction Database filed on Mar. 14, 2013, theentirety of which is expressly incorporated herein by reference.

An exemplary method of resolving a provisioning entity name can includea number of factors including, but not limited to, categories ofinformation associated with interactions, analyzing interactionsassociated with competitive and/or complementary provisioning entities.Such exemplary method can result in a significant uplift in accuracy inresolving the name of provisioning entities. In some embodiments, apercentage accuracy in resolving the name of provisioning entities canbe increased to high nineties (e.g., 97%).

FIG. 14 depicts a flowchart representing an exemplary process forestimating a location of a provisioning entity, consistent withembodiments of the present disclosure. While the flowchart discloses thefollowing steps in a particular order, it will be appreciated that atleast some of the steps can be moved, modified, or deleted whereappropriate, consistent with the teachings of the present disclosure.Process 1400 can be performed in full or in part by a provisioningentity analysis system (e.g., provisioning entity analysis system 210).It is appreciated that some of these steps can be performed in full orin part by other systems (e.g., such as those systems identified abovein FIG. 2).

In step 1410, a data structure (e.g., data structure 400) comprising aplurality of interactions associated with multiple entities can beaccessed. In some embodiments, the accessed data structure can comprisea plurality of categories of information showing interactions associatedwith multiple entities. The data structure can be similar to theexemplary data structure 400 described with reference to FIG. 4 above.The plurality of interactions of the data structure can include aconsuming entity and a provisioning entity. Each such interaction of thedata structure can include at least one attribute of the consumingentity and at least one attribute of the provisioning entity. In someembodiments, the at least one attribute of the consuming entity caninclude a location information of the consuming entity. For someconsuming entities, the location information may not be known oridentified.

Moreover, in some embodiments, the at least one attribute of theprovisioning entity can include an identification information of theprovisioning entity. In some embodiments, the at least one attribute ofthe provisioning entity can include an attribute other than anidentification information of the provisioning entity.

Next, in step 1420, an interaction of the data structure can beevaluated. Next, in step 1430, a determination can be made for theinteraction of the data structure as to whether the interaction includesan identified location information of the provisioning entity. In someembodiments, similar to the step 1330 of FIG. 13, the determination caninclude analyzing whether the categories of information associated witha location information of the provisioning entity are populated or not.If it turns out that the categories of information associated with alocation information of the provisioning entity are populated, then thedetermination can return a positive indication to signify that the atleast one attribute of the provisioning entity includes an identifiedlocation information of the provisioning entity and the process can thenmove to step 1460. If, on the other hand, the categories of informationassociated with a location information of the provisioning entity arenot populated, then the determination can return a negative indicationto signify that the interaction does not include a location informationof the provisioning entity and the process can move to step 1440.

In some embodiments, where the categories of information associated witha location information of the provisioning entity are populated, thedetermination can further include verifying that the populated data isvalid data that signifies a location information before the processmoves to step 1460. For example, for the category of informationrepresenting zip code (e.g., zip code sub-category 456), if thepopulated data is 94085, it can be verified as a valid data and theprocess can then move to step 1460. On the other hand, if the populateddata is 940850, it can be verified as an invalid data for zip code aszip codes, at least in the United States, are supposed to be only fivedecimal numerical digits and the process can then move to step 1440 asdescribed below. It will be understood that other methods to determinewhether the interaction includes a location information of theprovisioning entity can be implemented within the scope and spirit ofthis disclosure.

Next, if the interaction of the data structure does not include anidentified location information of the provisioning entity, step 1440can estimate a location information of the provisioning entity based onone or more attributes of one or more consuming entities. In someembodiments, step 1440 can estimate a location information of theprovisioning entity based on one or more attributes of one or moreconsuming entities and further based on one or more attributes of theprovisioning entity. For example, the one or more attributes of the oneor more consuming entities can be a location information of the one ormore consuming entities and the one or more attributes of theprovisioning entity can be an identification information of theprovisioning entity (e.g., provisioning entity identification category440). In some embodiments, a determination can be made based onidentification information of the provisioning entity to find outwhether the provisioning entity has more than one location. If thedetermination returns an answer in the negative, signifying that theprovisioning entity only has one location, information representing suchlocation can be identified by performing a search query over theInternet using a search engine (e.g., Google Search™).

In some embodiments, when the determination returns an answer in thepositive, signifying that there is more than one location for theprovisioning entity, a location information of the provisioning entitycan be estimated based on at least a location information of theconsuming entity and an identification information of the provisioningentity. For example, knowing a location information of the consumingentity (e.g., zip code of the consuming entity), a search query can berequested to find out a location information of the provisioning entitythat is closest to the location of the consuming entity. In someembodiments, the location information returned by the search query canbe an estimated location information of the provisioning entity.Alternatively, when there is more than one location for the provisioningentity, a location information of the provisioning entity can beestimated by looking at a frequency of interactions between theconsuming entity and each location of the provisioning entity. Forexample, a provisioning entity can be the grocery store, Safeway™, whichcan have multiple locations in a given zip code (e.g., 94086) of theconsuming entity. If the location of the Safeway™ where one or moreinteractions with a consuming entity occurred is unknown, interactionsbetween the same consuming entity and all Safeway™ locations within thegiven zip code of the consuming entity can be analyzed such that theSafeway™ location that is involved with the most number of interactionscan be selected as an estimated location of the Safeway™ for the one ormore interactions. It will be understood that the above-recitedestimation techniques are merely exemplary and not intended to belimiting.

Next, in step 1450, the data structure can be updated with an estimatedlocation information of the provisioning entity. In some embodiments,data associated with only the evaluated interaction can be updated.Alternatively, data associated with all interactions associated with theconsuming entity and the provisioning entity can be updated irrespectiveof whether those interactions were previously evaluated or not. Next, instep 1460, a determination can be made whether the data structurecomprises additional interactions that are to be evaluated. If thedetermination returns an answer in the positive, signifying that thereare additional interactions that are to be evaluated, the process can goback to step 1420 to evaluate another interaction and further to repeatthe process comprising steps 1420 through 1460, as described above. Onthe other hand, if the determination returns an answer in the negative,signifying that there are no additional interactions that are to beevaluated, the process can end.

FIG. 15 depicts a flowchart representing an exemplary process forestimating a location of a provisioning entity, consistent withembodiments of the present disclosure. While the flowchart discloses thefollowing steps in a particular order, it will be appreciated that atleast some of the steps can be moved, modified, or deleted whereappropriate, consistent with the teachings of the present disclosure.Process 1500 can be performed in full or in part by a provisioningentity analysis system (e.g., provisioning entity analysis system 210).It is appreciated that some of these steps can be performed in full orin part by other systems (e.g., such as those systems identified abovein FIG. 2).

The exemplary process of FIG. 15 can depict a multi-step process forestimating location information of a provisioning entity. Initially, anarea location information can be estimated to represent a locationinformation of the provisioning entity broadly. For example, an arealocation information for a grocery store like Safeway™ can be as broadas a state (e.g., California) or county (e.g., Santa Clara County) suchthat Safeway™ can comprise multiple possible locations within the arealocation. Later, a location information can be estimated to identify aspecific location of the provisioning entity from its multiple possiblelocations within the area location. For example, if the area locationinformation represents Santa Clara County comprising of ten possibleSafeway™ locations, the estimated location information can represent oneof the ten possible locations within Santa Clara County using either astreet address or other unique identifier for the location (e.g., zipcode if there is only one store location for the zip code). An exemplarymulti-step process is described below.

In step 1505, a data structure (e.g., data structure 400) comprising aplurality of interactions associated with multiple entities can beaccessed. In some embodiments, the accessed data structure can comprisea plurality of categories of information showing interactions associatedwith multiple entities. The data structure can be similar to theexemplary data structure 400 described with reference to FIG. 4 above.The plurality of interactions of the data structure can includeconsuming entities and provisioning entities. Each such interaction ofthe data structure can include at least one attribute of the consumingentity and at least one attribute of the provisioning entity. The atleast one attribute of the consuming entity can include locationinformation of the consuming entity. For some consuming entities, thelocation information may not be known or identified. Moreover, in someembodiments, the at least one attribute of the provisioning entity caninclude an identification information of the provisioning entity.Alternatively, the at least one attribute of the provisioning entity caninclude an attribute other than an identification information of theprovisioning entity.

The provisioning entity analysis system can receive an input that can beused in a process to fill in any missing categories of informationassociated with an interaction. For example, the received input can be“canonical data” that can be used to estimate identification informationof the provisioning entity. An exemplary canonical data can comprisedata that can be received from external to the provisioning entityanalysis system (e.g., Yelp™). For example, if a provisioning entityassociated with an interaction is an Italian restaurant, theprovisioning entity category 460 can be represented by an MCC 5812signifying it as a restaurant but might not be able to signify that itis an Italian restaurant. In such a scenario, canonical data such asYelp™ review information can be analyzed to further identify theprovisioning entity as an Italian restaurant. Another example forapplying received canonical data can be to differentiate between anentity that is no longer in business from an entity that might havechanged its name. In this example, canonical data can be received froman external source (e.g., Factual™) that can comprise a “status” flag aspart of its data, which can signify whether the entity is no longer inbusiness.

Next, in step 1510, an interaction of the data structure can beevaluated. Next, in step 1515, a determination can be made for theinteraction of the data structure as to whether the interaction includesan identified location information of the provisioning entity. In someembodiments, similar to the step 1430 of FIG. 14, the determination caninclude analyzing whether the categories of information associated witha location information of the provisioning entity are populated or not.If it turns out that the categories of information associated with alocation information of the provisioning entity are populated, then thedetermination can return a positive indication to signify that the atleast one attribute of the provisioning entity includes an identifiedlocation information of the provisioning entity and the process can thenmove to step 1555. If, on the other hand, the categories of informationassociated with a location information of the provisioning entity arenot populated, then the determination can return a negative indicationto signify that the interaction does not include location information ofthe provisioning entity and the process can move to step 1520.

In some embodiments, where the categories of information associated withlocation information of the provisioning entity are populated, thedetermination can further include verifying that the populated data isvalid data that signifies a location information before the processmoves to step 1555. For example, for the category of informationrepresenting zip code (e.g., zip code sub-category 456), if thepopulated data is 94085, it can be verified as a valid data and theprocess can then move to step 1555. On the other hand, if the populateddata is 094085, it can be verified as an invalid data for zip code aszip codes, at least in the United States, are typically only fivedecimal numerical digits and the process can then move to step 1520 asdescribed below. It will be appreciated that other methods to determinewhether the interaction includes location information of theprovisioning entity can be implemented within the scope and spirit ofthis disclosure.

Next, if the interaction of the data structure does not includeidentified location information of the provisioning entity, step 1520can estimate an area location information of the provisioning entitybased on one or more attributes of one or more consuming entities. Insome embodiments, step 1520 can estimate the area location informationof the provisioning entity based on one or more attributes of one ormore consuming entities. Alternatively, step 1520 can estimate the arealocation information of the provisioning entity based on one or moreattributes of one or more consuming entities and further based on one ormore attributes of the provisioning entity. For example, the one or moreattributes of the one or more consuming entities can be a locationinformation of the one or more consuming entities and the one or moreattributes of the provisioning entity can be an identificationinformation of the provisioning entity (e.g., provisioning entityidentification category 440). Alternatively, a determination can be madebased on identification information of the provisioning entity to findout whether the provisioning entity has more than one location. If thedetermination returns an answer in the negative, signifying that theprovisioning entity only has one location, information representing suchlocation can be identified by performing a search query over theInternet using a search engine (e.g., Google Search™) and suchinformation can be identified as an estimated first location informationof the provisioning entity.

In some embodiments, when the determination returns an answer in thepositive, signifying that there is more than one possible location forthe provisioning entity, an area location information of theprovisioning entity can be estimated based on at least a locationinformation of the consuming entity and an identification information ofthe provisioning entity. For example, knowing a location information ofthe consuming entity (e.g., zip code of the consuming entity), a searchquery can be requested to find out the area location information of theprovisioning entity that is within a predetermined distance (e.g.,within the same zip code) to the location of the consuming entity. Thelocation information returned by the search query can be an estimatedfirst location information of the provisioning entity.

Next, in step 1525, the plurality of interactions can be filtered toidentify other interactions (e.g., interactions other than the firstinteraction) between the one or more consuming entities and otherprovisioning entities (i.e., provisioning entities other than theprovisioning entity associated with the interaction and with anunidentified location). For example, step 1525 can filter otherinteractions such that interactions without an indication of locationinformation associated with the other provisioning entities need not beanalyzed. In some embodiments, the filtered interactions can be analyzedto filter provisioning entities based on a received canonical inputdata. For example, if the received canonical input data comprises anidentification information that might be missing in data structure 400,the system can filter the interactions further to only analyze thoseinteractions associated with provisioning entities with anidentification information that meet the criteria set by the receivedcanonical data. It will be appreciated that other forms of canonicaldata can be received within the scope of this disclosure.

Next, in step 1530, a travel time can be computed between a location ofa first provisioning entity to that of a location of a secondprovisioning entity. In some embodiments, the first provisioning entitycan be the provisioning entity with an estimated area location and thesecond provisioning entity can be any provisioning entity other than thefirst provisioning entity. For each interaction of step 1510 and itsassociated consuming entity, the second provisioning entity can be anyprovisioning entity other than the first provisioning entity that isassociated with other interactions of the consuming entity. Step 1530can be explained with the block diagrams of FIGS. 16A, 16B, and 16C,which depicts two provisioning entities, S1 and S2, five interactions,X1-X5, and exemplary travel times (e.g., T_(S1-X1)). Provisioningentities S1 and S2 can be two different locations within a chain ofstores associated with the same provisioning entity and situated withinan area location information estimated in step 1520. For example, S1 andS2 can be two different locations of Safeway™ situated within anestimated area location (e.g., zip code 94086). The area locationinformation can be depicted with a shaded region and labeled as element1605A in FIGS. 16A, 16B, and 16C. As shown in FIG. 16A, the fiveinteractions, X1-X5, can represent interactions between the consumingentity associated with the interaction of step 1510 and a provisioningentity other than S1 or S2. While FIGS. 16A, 16B, and 16C, depictlocations of two provisioning entities and locations of fiveinteractions, it will be appreciated that this disclosure is applicableto embodiments involving any number of provisioning entities and anynumber of interactions.

FIG. 16B depicts travel times between the Safeway™ location, S1, and aprovisioning entity involved in each of the interactions, X1-X5. Whilethe travel times are illustrated as aerial travel times, it isappreciated that the travel times can take into consideration roads,sidewalks, bike lanes, etc. For example, travel time between thelocation S1 and location of provisioning entity involved in interactionX1, can be represented by the line T_(S1-X1). Travel time T_(S1-X1) canbe computed using real-time traffic conditions or based on historicaltraffic conditions. Similarly, travel times can be computed between S1and each location of provisioning entities associated with interactionsX2 through X5. Such travel times can be labeled as T_(s1-x2) throughT_(S1-X5), as depicted in FIG. 16B.

FIG. 16C depicts travel times between the other possible Safeway™location, S2, and a provisioning entity involved in each of theinteractions, X1-X5. This process can be very similar to that of FIG.16B described above. For example, travel time between the location S2and location of provisioning entity involved in interaction X1, can berepresented by the line T_(S2-X1). Travel time T_(S2-X1) can be computedusing real-time traffic conditions or based on historical trafficconditions. Similarly, travel times can be computed between S2 and eachlocation of provisioning entities associated with interactions X2through X5. Such travel times can be labeled as T_(S2-X2) throughT_(S2-X5), as depicted in FIG. 16C.

Next, referring back to FIG. 15, in step 1535, an affinity score can becomputed. In some embodiments, an affinity score can be computed foreach possible location of the provisioning entity within the estimatedarea location. The computed affinity score can be based on the computedtravel times such that the affinity score can have an inverseproportionality with computed travel times such that the lower thetravel time the higher an affinity score. For example, based on theexemplary travel times depicted in FIGS. 16A, 16B, and 16C, it ispossible that the affinity score associated with location S1 is likelyhigher than that of location S2 because travel times associated with S1are lower than that of S2. Affinity score can be computed based on anaverage travel time for all interactions. Alternatively, affinity scorecan be computed by aggregating travel times of all interactions for eachlocation S1 and S2. It will be appreciated that the above-describedmethods are merely exemplary and other methods of computing an affinityscore based on travel times are possible within the scope of thisdisclosure. Alternatively, the computed affinity score can be normalized(e.g., can be normalized to comprise a value between 0 and 1, with 0representing no affinity and 1 representing maximum possible affinity).Moreover, while the affinity score can have an inverse relationship withthe computed travel times, it is appreciated that the affinity score canhave a proportional relationship to the computed travel times.

Next, in step 1540, the computed affinity score can be used to estimatea location information within the estimated area location for theprovisioning entity without an identified location information. Forexample, a location can be estimated by selecting the location which hasthe highest affinity score amongst all possible locations within thearea location. That is, in the exemplary embodiment of FIG. 16, locationS1 can be selected as the affinity score associated with location S1 islikely higher than that of location S2, as described above. It will beappreciated that other methods of estimating a second locationinformation based on an affinity score are possible. Alternatively, thecomputed affinity score can be used in conjunction with an algorithm toestimate a second location information within the area locationinformation.

In some embodiments, when there is more than one possible location forthe provisioning entity without an identified location information, alocation information within the area location of the provisioning entitycan be estimated by analyzing interactions between the consuming entityand other provisioning entities within the location of the consumingentity (e.g., zip code of the consuming entity) that are closely spacedin time relative to the interaction that does not include an identifiedlocation information of the provisioning entity. For example, a firstinteraction that does not include an identified location information ofthe provisioning entity can include a timestamp (e.g., time ofinteraction category 480) associated with the first interaction. Toestimate a location information for the provisioning entity associatedwith the first interaction, the system can analyze other interactions(e.g., interactions other than the first interaction) associated withthe consuming entity that occurred within the same location of theconsuming entity (e.g., zip code of the consuming entity), occurredwithin a short time interval of the timestamp of the first interaction(e.g., within 10 minutes of the timestamp), and which further include anidentified location information for the provisioning entities associatedwith the other interactions.

Alternatively, when there is more than one possible location for theprovisioning entity, a location information within the area location ofthe provisioning entity can be estimated by looking at a frequency ofinteractions between the consuming entity and each possible location ofthe provisioning entity. For example, a provisioning entity can be thegrocery store, Safeway™, which can have multiple locations in a givencity (e.g., Sunnyvale Calif.) of the consuming entity. Interactionsbetween the consuming entity and all Safeway™ locations within the givencity of the consuming entity can be analyzed such that the Safeway™location that is involved with the most number of interactions can beselected as an estimated location within the area location of theSafeway™ for the one or more interactions. It will be understood thatthe above-recited estimation techniques are merely exemplary and notintended to be limiting

Next, an accuracy check of the estimated location information within thearea location can be performed. In some embodiments, the accuracy checkcan comprise verification that the estimated location information is oneof the possible locations within the estimated area location of theprovisioning entity. Alternatively, the accuracy check can compriseverification that the estimated location information is a valid locationinformation. For example, if the estimated location information is astreet address, then the accuracy check can involve verifying that theestimated street address is a valid street address based on anInternet-based search using a search engine (e.g., Google Search™).

Next, in step 1545, the data structure can be updated with an estimatedlocation information of the provisioning entity. In some embodiments,the data structure can be updated with either an estimated area locationinformation or an estimated location within the area locationinformation. Alternatively, the data structure can be updated with boththe estimated area location information and the estimated locationinformation within the area location. In some embodiments, dataassociated with only the evaluated interaction can be updated.Alternatively, data associated with all interactions associated with theconsuming entity and the provisioning entity can be updated irrespectiveof whether those interactions were previously evaluated or not. Next, instep 1550, a determination can be made whether the data structurecomprises additional interactions that are to be evaluated. If thedetermination returns an answer in the positive, signifying that thereare additional interactions that are to be evaluated, the process can goback to step 1510 to evaluate another interaction and further to repeatthe process comprising steps 1510 through 1550, as described above. Onthe other hand, if the determination returns an answer in the negative,signifying that there are no additional interactions that are to beevaluated, the process can end.

In some embodiments, a provisioning entity analysis system can predict apurchasing pattern of consuming entities. For example, a provisioningentity (e.g., a large national retailer in the grocery business likeSafeway™) can be interested in predicting purchasing patterns ofconsuming entities in order to make decision such as opening new storesor closing existing stores. One method of predicting purchasing patternscan be to analyze interactions of consuming entities with theprovisioning entity. For example, if Safeway™ is interested in openingnew store by predicting purchasing patterns of their customers of anexisting location, the customer interactions at the existing locationcan be analyzed to understand where the customers are located byprocessing location information of the customers. Based on the processedlocation information of the customers of the existing location, Safeway™might be able to make a decision on a location for their new location.

Another method of predicting purchasing patterns can be to analyzeinteractions between the consuming entities and other provisioningentities, where the other provisioning entities can be either acompetitor of or complementary to the provisioning entity. For example,if Safeway™ is interested in opening new store by predicting purchasingpatterns of their customers of an existing location, interactions of thecustomers of the existing locations that are associated with acompetitive entity or a complementary entity can be analyzed. Anexemplary complementary entity can be a gas station or a pharmacybecause it can be reasonable to assume that consumers frequently shop ata pharmacy or a gas station that is close to their residential location.Accordingly, by analyzing interactions that are associated with acomplementary entity to estimate a residential location information ofconsumers, Safeway™ can make a decision on a location for their newlocation.

FIGS. 17-26 are screenshots of exemplary user interfaces, consistentwith the embodiments of the present disclosure. These user interfacescan be provided based on an analysis of a data structure (e.g., datastructure 400 of FIG. 4) performed by a provisioning entity analysissystem (e.g., provisioning entity analysis system 210). FIG. 17illustrates an exemplary user interface 1700 that a provisioning entityanalysis system (e.g., provisioning entity analysis system 210) cangenerate, according to some embodiments. In some embodiments, theexemplary user interface includes a dashboard, e.g a small businessportal dashboard (SBP) dashboard, that can depict a performance of anentity over a metric. For example, the SBP dashboard represents revenueinformation of the entity (e.g., a provisioning entity) for the currentweek (May 26, 2013-Jun. 2, 2013). In some embodiments, the SBP dashboardrepresents revenue information comparing the entity's actual revenue tothe entity's goal revenue for the week. For example, the provisioningentity can enter a goal revenue for a period of time (e.g., weekly,quarterly, or yearly). After receiving information regarding theexpected revenue, the provisioning entity analysis system can analyzeinteraction data to analyze the entity's performance relative to thegoal revenue. An outcome of such comparative analysis can be representedwith an exemplary bar graph or pie chart. For example, the middleportion of FIG. 17 depicts that the entity has received $48,078 inrevenues for the current week, and the entity's goal revenue for thatweek is $63,933.

In some embodiments, user interface 1700 can include a plurality of userinterface elements representing information associated with entityperformance metrics such as revenue, ticket size, new customers, andreturning customers. For example, as shown in FIG. 17, each of theabove-described user interface elements can be depicted as a rectangularbox with an icon and some information representing the performancemetric of the entity. The entity can customize what metrics aredisplayed and how those metrics are displayed. The user interfaceelements, when clicked on, can provide access to other user interfaces,depicting additional information for the selected performance metric.

User interface 1700 can include a sidebar with expandable labelsdepicting, for example, “My Store,” “My Customers,” and “MyNeighborhood.” Each of these labels can provide access to additionaluser interfaces that depict additional information for these metrics.For example, clicking on the “My Store” label can expand the label toshow submenus corresponding to “Revenue,” “Total Transactions,” “TicketSize,” “Busiest Days,” and “Busiest Hours.” Each of these submenus canprovide access to another user interface, providing additionalinformation for each category.

FIG. 18 shows a screenshot of an exemplary user interface 1800 thatrepresents revenue depicted temporally, consistent with someembodiments. A provisioning entity analysis system (e.g., provisioningentity analysis system 210) can generate exemplary user interface 1800.User interface 1800, for example, can be accessed by an entity selecting“Revenue” in the sidebar (e.g., “Revenue” submenu of user interface 1700of FIG. 17). User interface 1800 can represent revenue information in achart, such as the bar chart shown in the top panel of FIG. 18. In someembodiments, each bar in the bar chart can represent revenues for aperiod of time (e.g., a day, week, month, quarter, or year). Thegranularity or time period for each bar based on the selection of the“Monthly,” “Weekly,” and “Daily” boxes in the top left portion of thebar chart.

In some embodiments, user interface 1800 allows an entity to select aparticular bar or time period of interest. For example, the entity canselect the “May” bar. To indicate that “May” has been selected, userinterface 1800 can display that month in a different color. In someembodiments, user interface 1800 can also display additional informationfor the selected bar. For example, as shown in FIG. 18, user interface1800 can display the month selected, the revenue for that month, theaverage ticket size, the number of transactions, and the names ofholidays in that month, if any. In some embodiments, user interface 1800can depict comparisons of revenue information. For example, userinterface 1800 can display additional lines or bars (not shown), whichrepresent revenue competitor revenue, industry revenue, or entityrevenue from another time period. In some embodiments, user interface1800 can include a bottom panel depicting a bar chart of revenue for alonger period of time, such as the past twelve months. User interface1800 can highlight the region currently depicted in the top panel bychanging the color of the corresponding bars in the bottom panel. Insome embodiments, user interface 1800 can allow an entity to drag thehighlighted region on the bottom panel to depict a different time periodin the top panel.

User interface 1800 can also allow an entity to access additional userinterfaces by selecting, for example, the “Total Transactions,” “TicketSize,” “Busiest Days,” or “Busiest Hours” submenus in the sidebar. Insome embodiments, these user interfaces (not shown) can displayinformation in the same manner as user interface 1800. For example, auser interface for “Total Transaction” can represent transactioninformation in a chart, such as a bar chart shown in the top panel ofFIG. 18. In this user interface, the bars in the bar chart can representthe total number of transactions for a period time (e.g., one month).User interfaces accessed through the “Ticket Size,” “Busiest Days,” and“Busiest Hours” can display information similarly. In some embodiments,the bars in these user interfaces can represent a percentage for aperiod time (e.g., 15% of sales occur on Tuesday).

FIG. 19 depicts a screenshot of an exemplary user interface representingnew customer acquisition numbers over a selected period, consistent withsome embodiments. A provisioning entity analysis system (e.g.,provisioning entity analysis system 210) can generate exemplary userinterface 1900. In some embodiments, user interface 1900 is accessibleby expanding “My Customers” in the sidebar and selecting the “NewCustomers” submenu. User interface 1900 can depict customer metrics fora selected period of time. For example, user interface 1900 can displaycustomer metrics for a selected quarter. User interface 1900 can use,for example, a bar graph to represent the customer metrics wherein eachbar represents the number of customers for a subset period of time,(e.g., a week) within the longer period of time (e.g., a quarter).

User interface 1900 can also depict new customers in one color andreturning customers in a different color to distinguish between thedifferent types of customers. As an example, in FIG. 19, returningcustomers are represented by the upper, lighter portions of the bar,whereas new customers are represented by the lower, darker portions. Insome embodiments, user interface 1900 can depict the total number of newcustomers and returning customers for a selected time period, as shownin the top right portion of user interface 1900. User interface 1900 canalso allow an entity to access additional user interfaces (such as userinterface 2000 and user interface 2100 described below) by selecting,for example, the “Loyal Customers” or “Where do they spend?” submenus.

FIG. 20 depicts a screenshot of an exemplary user interface 2000representing loyal customer information, consistent with someembodiments. A provisioning entity analysis system (e.g., provisioningentity analysis system 210) can generate exemplary user interface 2000In some embodiments, user interface 2000 can be accessed based on theselection of the “Loyal Customers” submenu in the sidebar. Userinterface 2000 can depict performance metrics relating to revenue fromreturning customers. In some embodiments, user interface 2000 representsthis information as a stacked bar graph. A section of the stacked graphcan represent the number of customers who visited an entity a certainnumber of times. For example, the bottom section of the stacked barchart depicted in FIG. 20 can represent the number of customers whovisited once. In some embodiments, a section of the stacked graph canrepresent the number of customers whose visits fall within a range oftimes, (e.g., “3-4 times” or “9+ times”). User interface 2000 can depicteach section as a percentage (e.g. 7.0% of customers), as a number (e.g.149 customers), or as a combination thereof (e.g., 149 customers, 7.0%).

In some embodiments, user interface 2000 can depict additionalinformation for a section selected by the entity. For example, theentity can select the “9+ times” section at the top of the stacked bargraph in FIG. 20 to display additional information about thosecustomers. This information can include the total revenue from thosecustomers, the total number of transactions with those customers, andthe average ticket size of those customers.

FIG. 21 depicts a screenshot of an exemplary user interface 2100representing customer spending habits for specific geographic regions. Aprovisioning entity analysis system (e.g., provisioning entity analysissystem 210) can generate exemplary user interface 2100. In someembodiments, user interface 2100 can be accessed based on the selectionof the “Where do they spend” submenu in the sidebar. User interface 2100can depict a geographic region. User interface 2100 can also depictlocations where customers spend overlaid on the geographic region, e.g.a heat map. For example, the shaded regions overlaid on the geographicregion in FIG. 21 can depict the regions where customers spend.

Different shades of gray-scale can be used to show different amounts ofspending (e.g., darker shaded regions can depict regions where customersspend more). Alternatively, a color coded heat-map can be used wheredifferent colors can be used to show different amounts of spending. Insome embodiments, the geographic granularity (e.g., district, city,county, metropolitan area, state) of user interface 2100 is selectable.User interface 2100 can also depict spending habits for the geographicregion for different temporal periods. For example, user interface 2100can depict customer spending for the current month, quarter, previousquarter, or any other time period.

FIG. 22 depicts a screenshot of an exemplary user interface 2200representing entity performance using one or more filter selectionsincluding demographics, geographic location, time period, andtransactions. A provisioning entity analysis system (e.g., provisioningentity analysis system 210) can generate exemplary user interface 2200.In some embodiments, an entity can utilize user interface 2200 tocompare how different variables (e.g., time, demographics, location,etc.) affect entity performance metrics (e.g., revenues, ticket size,etc.). In some embodiments, user interface 2200 can depict entityperformance using a bar chart or histograms. For example, the bar chartsin the middle of FIG. 22 depict the average ticket size based on thenumber of times a customer visits. The bar chart on the left side ofFIG. 22 depicts this information for the current quarter, for customersaged 31 to 49, for sales on Saturday, whereas the bar chart on the rightdepicts the same information for the current quarter, for customers,aged 31 to 49, for every day of the week. User interface 220 allows anentity to use these bar charts to determine the effect the day of theweek has on the number of tickets and the average ticket size.

In some embodiments, user interface 2200 can depict additional customerinformation, such as income, as a histogram. As shown in FIG. 22, thehistogram can represent customer demographics for the selected filters.In some embodiments, user interface 220 can depict a delta (not shown inFIG. 22) representing a difference between similar categories in eachhistogram. The depiction of the delta can be in the area between theleft and right histograms such as shown in U.S. application Ser. No.14/289,596 at FIG. 17, the depiction of which is incorporated byreference. For example, if 16% of the entity's customers had an incomeless than $30,000 for the first filter selections, and only 11% had anincome less than $30,000 for the second filter selections, userinterface 2200 can display a 5% delta to the left, representing thedifference between the filter selections.

FIG. 23 depicts a screenshot of an two exemplary user interfaces. Aprovisioning entity analysis system (e.g., provisioning entity analysissystem 210) can generate these exemplary user interfaces. The left panelof FIG. 23 shows a user interface that can depict business insights forthe entity (e.g., what customers buy, where they buy, when they buy, howoften they buy, where they live, how much they make, etc.). For example,user interface 2300 can depict insights such as temporal trends,temporal summaries, geographical trends, whether customers are onvacation, and customer demographics. An entity can use these insights topredict future spending, to target specific customers, to determine whento have sales, to determine when to order additional inventory, etc. Theright panel of FIG. 23 shows a user interface that can depict anexemplary temporal graph of revenues. This bar chart is similar to thebar chart described above with respect to FIG. 18. In some embodiments,the user interface in the right panel can allow an entity to compare itsrevenues to other entities. For example, the lines on each bar in theright panel of FIG. 23 represent competitor revenue for the selectedtime period. In some embodiments, these lines can represent industryrevenue or entity revenue from another time period. In some embodiments,the user interface shown in the right panel of FIG. 23 can include abottom panel depicting a bar chart of revenue for a longer period oftime, such as the past twelve months. The user interface can highlightthe region currently depicted in the top panel by changing the color ofthe corresponding bars in the bottom panel. In some embodiments, theuser interface allows an entity to drag the highlighted region on thebottom panel to depict a different time period in the top panel.

FIG. 24 depicts a screenshot of an exemplary user interface 2400including a heat-map representation (e.g., the left panel) andgraph-based representation (e.g., the right panel) of entityperformance. A provisioning entity analysis system (e.g., provisioningentity analysis system 210) can generate exemplary user interface 2400.In some embodiments, the entity can select one or more filters (e.g.“Add New Filter” shown in the sidebar) to display a timeline ofcustomer. For example, user interface 2400 can represent customerspending on a daily basis. In some embodiments, user interface 2400 canrepresent customer spending with a heat map, such as the heat map shownin the left panel of FIG. 24. The heat map can be used to accuratelypredict the geographic locations of future customer spending. In someembodiments, customer spending can be represented as a graph-basedrepresentation where the independent axis (e.g., x-axis) can represent aperiod of time and the dependent axis can represent customer spending,as depicted in the right panel of FIG. 24. In some embodiments, thegraph-based representation can be used as a predictive chart to predictfuture customer spending.

FIG. 25 depicts a screenshot of an exemplary user interface 2500representing inferred customer location. A provisioning entity analysissystem (e.g., provisioning entity analysis system 210) can generateexemplary user interface 2500. In some embodiments, user interface 2500can represent customer location inferred from persistent information(e.g., the centroid of the customer's medical transactions or the medianof the customer's retail food and pharmacy stores transactions). In someembodiments, user interface 2500 can represent customer locationinferred from contextual information (e.g. localized small-ticketspending in severe weather or spending after an inferred move). In someembodiments, user interface 2500 can represent temporal customerlocation (e.g., permanent, temporary, seasonal, etc.).

In some embodiments, customer location can be represented by a circle ofa particular distance, wherein the provisioning entity analysis systeminfers that the customer is located within that circle. For example, inFIG. 25, the inner circle represents a two mile range and the outercircle represents a five mile range. In some embodiments, user interface2500 can depict a confidence metric corresponding to the accuracy ofinferred customer location (e.g., 75-80% confident that the customer iswithin the inner circle and 90-95% confident that the customer islocated in the outer circle).

FIG. 26 depicts a screenshot of an exemplary user interface 2600representing predictive travel and vacation spending. Entities, such asresorts and travel destinations, can use this information to predictvacation patterns, enabling them to develop targeted marketing and toinform future restaurant and service selection. A provisioning entityanalysis system (e.g., provisioning entity analysis system 210) cangenerate exemplary user interface 2600. The provisioning entity analysissystem can use the inferred customer locations described above todetermine whether certain transactions qualify as travel or vacationspending. In some embodiments, user interface 2600 can depict travel orvacation spending as a chart. For example, as shown in FIG. 26, userinterface 2600 can represent this information as a scatter chart withconfidence intervals. The independent axis (e.g., x-axis) of the chartcan represent the day of vacation. The dependent axis can represent theaverage range of percentage of travel spending that is spent onrestaurants.

In the foregoing specification, embodiments have been described withreference to numerous specific details that can vary from implementationto implementation. Certain adaptations and modifications of theembodiments described herein can be made. Therefore, the aboveembodiments are considered to be illustrative and not restrictive.

What is claimed is:
 1. A system comprising: one or more processors;memory storing instructions that, when executed by the one or moreprocessors, cause the system to perform: receiving input for at leastone category of a plurality of categories of information to be comparedbetween a first entity and a second entity; accessing a data structurein the memory comprising the plurality of categories of information, theplurality of categories of information showing a plurality ofinteractions between multiple entities, the multiple entities includingat least the first entity and the second entity; estimating an identityof the second entity based on information in the data structurerepresenting at least a type of the first entity and a location of thefirst entity; processing information associated with one or moreparticular interactions of the data structure for comparing data betweenthe first entity and the second entity, the one or more particularinteractions being associated with the at least one category of theplurality of categories of information; and providing the processedinformation for displaying a comparison between a performance of thefirst entity and the second entity on a user interface.
 2. The system ofclaim 1, wherein the first entity comprises a first provisioning entity,and the second entity comprises a second provisioning entity.
 3. Thesystem of claim 1, wherein an identity of the first entity is known, andthe identity of the second entity is unknown.
 4. The system of claim 1,wherein the estimating the identity of the second entity comprisesanalyzing the data structure in the memory to identify a set of entitieshaving the type of the first entity and being within a predeterminedproximity of the location of the first entity.
 5. The system of claim 4,wherein the instructions further cause the system to select a particularentity of the set of entities as the estimated identity of the secondentity, the particular entity of the set of entities being closer inproximity to the location of the first entity than the other entities ofthe set of entities.
 6. The system of claim 1, wherein each of theplurality of interactions comprises categories of information includingat least one of: an interaction number category, a consuming entityidentification category; a consuming entity location category, aprovisioning entity identification category, a provisioning entitylocation category, a type of provisioning entity category, aninteraction amount category, and a time of interaction category.
 7. Thesystem of claim 1; wherein the processing information associated withone or more particular interactions of the data structure for comparingdata between the first entity and the second entity comprises:processing information associated with the at least one category ofinformation of the first entity; and processing information associatedwith the at least one category of the second entity.
 8. The system ofclaim 7, wherein the comparison between the performance of the firstentity and the second entity comprises a comparison of the processedinformation associated with the at least one category of information ofthe first entity and the processed information associated with the atleast one category of the second entity.
 9. The system of claim 8;wherein the user interface includes a dashboard showing a graphicalrepresentation associated with the comparison of the processedinformation associated with the at least one category of information ofthe first entity and the processed information associated with the atleast one category of the second entity.
 10. A method implemented by acomputing system including one or more processors and storage mediastoring machine-readable instructions; wherein the method is performedusing the one or more processors, the method comprising: receiving inputfor at least one category of a plurality of categories of information tobe compared between a first entity and a second entity; accessing a datastructure in the memory comprising the plurality of categories ofinformation; the plurality of categories of information showing aplurality of interactions between multiple entities; the multipleentities including at least the first entity and the second entity;estimating an identity of the second entity based on information in thedata structure representing at least a type of the first entity and alocation of the first entity; processing information associated with oneor more particular interactions of the data structure for comparing databetween the first entity and the second entity, the one or moreparticular interactions being associated with the at least one categoryof the plurality of categories of information; and providing theprocessed information for displaying a comparison between a performanceof the first entity and the second entity on a user interface.
 11. Themethod of claim 10, wherein the first entity comprises a firstprovisioning entity, and the second entity comprises a secondprovisioning entity.
 12. The method of claim 10, wherein an identity ofthe first entity is known, and the identity of the second entity isunknown.
 13. The method of claim 10, wherein the estimating the identityof the second entity comprises analyzing the data structure in thememory to identify a set of entities having the type of the first entityand being within a predetermined proximity of the location of the firstentity.
 14. The method of claim 13, further comprising selecting aparticular entity of the set of entities as the estimated identity ofthe second entity, the particular entity of the set of entities beingcloser in proximity to the location of the first entity than the otherentities of the set of entities.
 15. The method of claim 10, whereineach of the plurality of interactions comprises categories ofinformation including at least one of: an interaction number category, aconsuming entity identification category, a consuming entity locationcategory, a provisioning entity identification category, a provisioningentity location category, a type of provisioning entity category, aninteraction amount category, and a time of interaction category.
 16. Themethod of claim 10, wherein the processing information associated withone or more particular interactions of the data structure for comparingdata between the first entity and the second entity comprises:processing information associated with the at least one category ofinformation of the first entity; and processing information associatedwith the at least one category of the second entity.
 17. The method ofclaim 16, wherein the comparison between the performance of the firstentity and the second entity comprises a comparison of the processedinformation associated with the at least one category of information ofthe first entity and the processed information associated with the atleast one category of the second entity.
 18. The method of claim 17,wherein the user interface includes a dashboard showing a graphicalrepresentation associated with the comparison of the processedinformation associated with the at least one category of information ofthe first entity and the processed information associated with the atleast one category of the second entity.
 19. A non-transitory computerreadable medium comprising instructions that, when executed, cause oneor more processors to perform: receiving input for at least one categoryof a plurality of categories of information to be compared between afirst entity and a second entity; accessing a data structure in thememory comprising the plurality of categories of information, theplurality of categories of information showing a plurality ofinteractions between multiple entities, the multiple entities includingat least the first entity and the second entity; estimating an identityof the second entity based on information in the data structurerepresenting at least a type of the first entity and a location of thefirst entity; processing information associated with one or moreparticular interactions of the data structure for comparing data betweenthe first entity and the second entity, the one or more particularinteractions being associated with the at least one category of theplurality of categories of information; and providing the processedinformation for displaying a comparison between a performance of thefirst entity and the second entity on a user interface.
 20. Thenon-transitory computer readable medium of claim 19, wherein theestimating the identity of the second entity comprises analyzing thedata structure in the memory to identify a set of entities having thetype of the first entity and being within a predetermined proximity ofthe location of the first entity.